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Description 

[0001] The present invention relates generally to a 
method and apparatus for personal computer (PC) mon- 
itoring and control and more specifically to a method and 
apparatus for enabling a PC to which the apparatus is 
connected (hereinafter referred to as a "Host" PC) to be 
accessed, restarted, operated and/oreontrolled remote- 
ly by another PC (hereinafter referred to as a "Remote" 
PC) using standard public utility telephone lines or direct 
cabling. The invention further permits a Remote PC to 
access Host processing status information and/or re- 
start (i.e. reboot) the Host PC without Central Process- 
ing Unit (CPU) support from the Host PC. In particular, 
the present invention relates to a computer monitoring 
system according to the preamble of claim 1 and to a 
method according to the preamble of claim 11 . 
[0002] Millions of PCs are presently in use. Each PC 
includes various hardware components including a 
CPU, keyboard, mouse, video display adapter card/cir- 
cuit (hereinafter referred to as "VDAC"), video display 
monitor (hereinafter referred to as "VDM"), and/or one 
or more mass storage devices. Other special purpose 
hardware devices such as a modem, voice or sound 
card, or network interface adapter card may be connect- 
ed to or installed within a PC. 

[0003] Presently, a VDM is normally either an analog 
or TTL (digital) display device that connects to either a 
15 pin or 9 pin receptacle on a PC's VDAC. A PC's 
VDAC normally sends video signals to a VDM in either 
a monochrome, CGA, EGA, or VGA format known to 
persons familiar with the trade. The present invention, 
however, is not to be limited to these video formats and 
will operate with any video format when properly config- 
ured. 

[0004] PC's may be accessed and controlled remotely 
by other PC's by essentially two different types of proc- 
esses. First, a hardware network interface adapter card 
or device may be installed or connected to a PC. This 
interface device is then connected, either using a cable 
or through the airways using a wireless network inter- 
face device, to other PCs attached to a Local Area Net- 
work (LAN). All such devices require Host CPU support 
(via network interface software installed in the PC's 
memory) to permit a Remote PC to access or control a 
Host PC. Personsfamiliarwith the trade referto this type 
of process as "peer to peer" PC networking. 
[0005] Second, a memory resident software system 
may be installed on a Host PC having access to a mo- 
dem, which would then permit the Host PC to be remote- 
ly controlled over standard telephone lines by another 
Remote PC having access to a modem and compatible 
memory resident interface software operating on the 
Remote PC. Again, in this case the ability of the Remote 
PC to control and access the Host PC depends on CPU 
processing support being provided by both PC's and a 
memory resident software system being pre-installed on 
the Host PC to acknowledge and process an incoming 



call from the Remote PC. 

[0006] In many cases control of a PC is not always 
practical or possible remotely. Many PC based applica- 
tion software systems take over a PC completely and, 
s due to memory restrictions or other processing conflicts, 
cannot co-exist with those software systems permitting 
Remote PC access. Moreover, even in cases where the 
required Host and Remote access interface software 
has been successfully installed, if the Host processor 
should lock-up or otherwise fail, remote users immedi- 
ately lose their ability to access the Host system. In such 
cases the Remote user would not be able to remotely 
access information displayed on the Host PC's VDM 
screen afterthe lock-up occurred. Information displayed 
on the VDM screen, however, usually indicates why the 
failure occurred and the status of processing at the point 
of failure, and therefore can be particularly useful in an- 
alyzing the PC failure and in preventing future similar 
failures. 

[0007] Numerous PC monitoring systems are pres- 
ently available to automatically alert designated persons 
via pagers, pre-recorded voice alerts or electronic mail 
when a PC or application running on a PC has failed. 
When such failures occur, the persons being notified 
may be in remote locations (e.g. at home) not able to 
physically access the PC that has failed. 
[0008] After a failure alert is issued, persons alerted 
typically have access to a Remote PC, but may not be 
able to access a desired Host PC because the Host CPU 
has locked up and will no longer respond to user input, 
the application running on the Host system does not 
support or condone Remote PC access, orthe Host sys- 
tem does not have the required software installed to per- 
mit a Remote PC to access the Host PC. When a Host 
CPU has locked up or a program error has occurred, 
vital information, as to the exact nature of the problem 
which ha%occurred is often displayed on the PC's VDM 
screen. Normally, this information must be viewed and/ 
or analyzed before corrective action can be taken. De- 
vices presently exist that permit a PC to be remotely or 
automatically re-booted, which in many cases restores 
normal processing after an alert is issued. However, per- 
sons alerted are reluctant to use such devices without 
first looking at the PC's VDM screen to determine what 
may have caused the failure, so that similar failures can 
be prevented. In other cases, information on the VDM 
screen may be necessary to successfully re-start an ap- 
plication that has failed from the point of failure. 
[0009] Many PC users need to remotely monitor and 
control another PC, where, due to processing restric- 
tions or limitations, it may not be possible to use the PC's 
processor to access a particular PC remotely. For ex- 
ample, for security reasons, a bank may wish to dis- 
creetly monitor PC usage by tellers or loan officers from 
a central, off-site location. As a second example, a Net- 
work Manager may wish to periodically remotely monitor 
and control the activities of a dedicated network file sery- 
. er or tape backup workstation. As a third example, un- 
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skilled on-site PC users may need a simple means to 
permit PC maintenance personnel to have extensive re- 
mote access to their PCs, and particularly to a network 
file server, in the event of trouble or failure. 
[0010] Numerous software systems are available 
which are designed to link one PC with other PCs using 
modems connected via standard telep hone lines. These 
systems permit a Host PC to be controlled by a Remote 
PC. Special functions keys and menus are used by 
these software systems that permit these products to 
operate a Host PC from a Remote PC as if the remote 
user was physically sitting at the Host PC. Examples of 
such packages include Crosstalk™, developed by Dig- 
ital Communications Associates, Inc., 1000 Alderman 
Dr., Alpharetta, GA 30202-1000 (404442-4000); Pro- 
comm Plus™, developed by Datastorm Technologies 
Inc., 3212 Lemone Blvd, Columbia, MO 65201, 
(314443-3282); or Unicom™, developed by Data 
Graphics, P.O. Box 58517, Renton, WA 98058 
(206-432-1201). Each of these products requires 
processing support and memory from the Host PC and 
will halt if Host processing should lock-up or fail. Also, 
if these products are not pre-installed on the Host PC, 
remote access will not be possible and no provision is 
made by these products to save VDM screen history or 
to capture an active VDM screen when a PC has locked- 
up. Finally, these products assume software based con- 
trol of the keyboard and/or mouse, as opposed to as- 
suming physical control over the PC's keyboard and/or 
mouse, which is less restrictive. 

[0011] Network software utility programs exist that 
permit one workstation to access and control the activ- 
ities of another workstation connected to the network. 
Products that fall into this category include, Carbon 
Copy™ for LANs, developed by Microcom Inc., 500 Riv- 
er Ridge Drive, Norwood, MA 02062 (617-551-1000); 
and Map Assist, developed by Fresh Technology Com- 
pany, 1478 North Tech Boulevard, Suite 101 , Gilbert Ar- 
izona, 85234 (602-4974200). Similar to the other remote 
access utility programs, these products require software 
resident in the Host PC's memory to operate. Neither 
remote control nor access will be possible if the Host PC 
should lock-up or fail. 

[0012] Utility software programs exist that are de- 
signed to convert graphics image data captured by doc- 
ument scanners into text data, so that the resulting text 
data can be manipulated and edited using word 
processing software products. Examples of such pro- 
grams include, OmniPage Professional™, developed 
by Caere Corp, 100 Cooper Ct, Los Gatos, CA 95030 
(408-395-7000); Perceive™, developed by Ocron, 3350 
Scott Blvd., #36, Santa Clara, CA 95054; TypeRead- 
er™, developed by ExperVision Inc., 3590 N. First St., 
San Jose, CA 951 34 (408-428-9444); and WordScan™ 
Plus, developed by Calera Recognition Systems, 475 
Potrero Ave., Sunnyvale, CA 94086 (408-720-8300). 
Such programs obtain source input data from digitized 
output of static data files created by document scanners 



as opposed to capturing, decoding then converting to 
text the output signals of a PC's video display adapter 
cards/circuits (VDAC) as the signals are occurring (i.e. 
on a real time basis). In addition, such utility programs 
5 depend on CPU support from the PC where they are 
installed, cannot transmit data related to the status of 
processing in the event the PC should fail, and provide 
for no remote keyboard and/or mouse control. 
[0013] Devices exist that permit using a central key- 

10 board and monitor to control and access multiple PC's. 
Examples of such products include Commander™, de- 
veloped by Cybex Corporation, 2800-H Bob Wallace 
Ave. Huntsville, Alabama (205-534-0011); Master Con- 
sole™ developed by Raritan Computer, Inc., 10-1 llene 

15 Court, Belle Mead, NJ 08502; and Plex developed by 
Data Vision Inc., 370 West Camino Gardens Blvd, Boca 
Raton, Florida, 33432 (407-482-3996). These products 
require the keyboard and PC interface cables to be di- 
rectly connected to one or more physical cable switching 

20 device(s). The VDAC signals are merely boosted and 
transferred as video signals over direct dedicated ca- 
bling. No attempt is made to convert the signal output 
of the VDAC to a digital form suitable transmission over 
public utility telephone lines or other communication net- 

25 work. Similarly, the keyboard used by the central unit is 
connected directly to each PC controlled with local wir- 
ing and no attempt is made to control keyboards using 
the public telephone system or to support keyboards ex- 
isting at both the remote console and Host PC. 

30 [0014] Devices exist that transmit a composite (TV) 
video signal over a telephone line. Such products in- 
clude the PhoneViewer, distributed by Home Automa- 
tion Lab, 5500 Highlands Pkwy, Suite 450, Smyrna, GA 
30082-5141 and AT&T's video phone, developed by 

35 AT&T, 14250 Clayton Road, Baldwin, Missouri 63011, 
1 -800437-9504. These products rely on a video camera 
to periodically capture a picture which is then transmit- 
ted to a screen on the remote caller's video phone. 
These systems convert the video camera images cap- 

^0 tured to bitmapped graphical images. No attempt is 
made to decode the data captured into text data. Fur- 
thermore, such products are not capable of decoding 
and transmitting the video signals produced by a PC's 
VDAC. If such products were used to simply snap a pic- 

^5 ture of the PC's VDM screen, the resulting data trans- 
mitted would be slow and of a poor quality, particularly 
if the PC video output changed during the period when 
the video snapshot is being taken. Moreover, none of 
these products provide a PC keyboard/mouse tele- 

50 phone interface necessary to control a Remote PC. 
Even if such an interface were provided, the user may 
require a separate phone line to access the Remote PC, 
so as to not interfere with the transmission of video 
graphics image data derived from the composite video 

55 snapshot. 

[0015] Devices exist that permit a video signal to be 
captured by a PC from an external analog video record- 
ing device, such as a video camera, and the signal con- 
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verted into a digital format suitable for display on a PC's 
VDM using a video capture adapter card inserted into a 
PC. One such device is the Smart Video Recorder man- 
ufactured by Intel Corp., P.O. box 58130, Santa Clara, 
CA 95052 (800-955-5599). Such devices require a ded- 
icated cable to be directly connected from the video cap- 
ture adapter card to the video recording device, and 
none of these products provide a PC keyboard/mouse 
telephone interface necessary to control a Remote PC. 
[0016] Numerous devices exist that permit a PC to be 
re-booted remotely such as the Sentry Remote Power 
Manager, developed by Server Technology, 2332-B 
Walsh Ave. Santa Clara, CA 95051 (408-988-0142), 
Tone Operated Switch (TOPS) developed by Black Box 
Corp., P.O. Box 12800, Pittsburgh PA 15241 
(412-746-5530) orTELEBOOT developed by Fox Net- 
work Systems, 15200 Shady Grove Road, Suite 350, 
Rockville Md 20750 (301 -924-2264). Once such system 
is described in U.S. Patent No. 5,566,339 filed October 
23, 1 992 and assigned to assignee of the present inven- 
tion, the contents of which are incorporated by reference 
herein. These devices, however, provide no remote vid- 
eo display or keyboard/mouse interface capabilities. 
[0017] U.S. Patent No. 5,153,886 to Turtle discloses 
a visual display signal processing system and method 
used for regression testing of computer hardware and/ 
or software applications. The system disclosed in Turtle, 
however, relies upon connection to the internal video 
adapter circuitry and does not operate to interpret video 
raster signals generated by the video display adapter 
circuit. Furthermore, the system disclosed in Turtle is in- 
trusive since it requires a circuit card to be installed into 
a computer to be tested, and cannot be easily connected 
to a computing device using the existing standard inter- 
face connectors. 

[001 8] U.S. Patent No. 5,084,875 to Weinbert er et al. 
discloses a system for automatically monitoring copiers 
from a remote location and allowing operation of a cop- 
ier from a remote location. Weinberger et al., however, 
does not disclose a system suitable for use in remote 
monitoring and control of a personal computer system 
or network, and further does not disclose a system 
which can monitor and forward video raster signals gen- 
erated by a remote computer system. 
[0019] U.S. Patent No. 5,124,622 to Kawamura et al. 
discloses a system for remote diagnosis of a numerical 
apparatus. Again, however, Kawamura et al. does not 
disclose a system which can monitor and forward video 
raster signals generated by a remote computer system. 
Additionally, Kawamura et al. does not disclose a sys- 
tem for use in remote monitoring and control of a per- 
sonal computer system or network. 
[0020] U.S. Patent No. 5,237,677 to Hirosawa et al. 
discloses a monitoring and controlling system and meth- 
od for a data processing system in which report of a fault 
occurrence is automatically effectuated to a remotely lo- 
cated supervision/control system. Hirosawa et al., how- 
ever, fails to disclose a system that can monitor the vid- 



eo raster signals generated by a remote data processing 
system. 

[0021 ] FR 2 672 707 A1 , which forms the starting point 
of the present invention, discloses a method for remote 
maintenance or controlling a host computer. The video 
signal generated by the host computer and received by 
an associated display terminal can be converted by the 
host computer into digital signals and sent via a modem 
in the host computer to a remote computer. If the host 
computer is locked up, any monitoring of information 
contained in the video signal cannot be generated and 
transmitted to the remote computer. 
[0022] Object of the present invention is to provide an 
improved system and method for remotely controlling a 
data-processing device at a remote location. 
[0023] The above object is achieved by a computer 
monitoring system according to claim 1 or by a method 
according to claim 11 . Preferred embodiments are sub- 
ject of the subclaims. 

[0024] The present invention permits a Remote PC to 
access and control a Host PC. The system includes a 
microprocessor controlled computer hardware device, 
(hereinafter referred to as a "Host Unit"), software pro- 
grams operating on the Host PC, and software pro- 
grams operating on the Remote PC. 
[0025] The connection between a Host PC and Re- 
mote PC can be accomplished through either of two 
means. As a first means, a modem is connected to the 
Remote PC's serial interface port and a compatible mo- 
dem is connected to a data interface port on the Host 
Unit. On this basis, a Remote PC could communicate 
with a Host site via a standard telephone line linkage 
between the two modems. This means is hereinafter re- 
ferred to as a "Modem Linkage". 
[0026] As a second means, a remote PC could be 
connected by a dedicated cable from a data transfer port 
of the PCye.g. a serial or parallel port) directly to a data 
interface port on the Host Unit. This means is hereinafter 
referred to as a "Direct Line Linkage". The Direct Line 
Linkage means supports greater data transfer rates 
than the Modem Linkage means and the Direct Line 
Linkage means avoids the need to use modems. 
[0027] However, the Direct Line Linkage means does 
not provide the same flexibility for off site remote access 
to a Host Unit as does the Modem Linkage means. 
[0028] The Host Unit contains it's own microproces- 
sor (or other computing circuitry) designed to capture, 
interpret and store information displayed on a Host PC's 
VDM screen from the video raster signal output of the 
Host PC's VDAC (i.e. a video raster signal is that video 
output signal of a VDAC which serves as direct input 
into a VDM). VDM screen data collected in this manner 
permits a Remote userto access, obtain, view, and store 
Host PC current and previous VDM screen data on a 
Remote PC after linking the Remote PC to the Host Unit, 
VDM screen data captured, interpreted and stored by a 
Host Unit from the Host PC's VDAC raster output may 
be either text or graphics (i.e. image) based and may be 
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In either color or monochrome. Host VDAC video raster 
signal output display formats captured and interpreted 
by a Host Unit include monochrome, CGA, EGA, and 
VGA modes, which are known to persons familiar with 
the trade, and similar techniques could be used for any 
display format. 

[0029] In addition, the invention permits a Remote PC 
to (1 ) physically redirect keyboard and/or mouse control 
from a keyboard and/or mouse connected to a Host PC 
at the Host Site to the keyboard and/or mouse connect- 
ed to the Remote PC, thereby allowing the Remote PC 
to fully control keyboard and/or mouse input to the Host 
PC, (2) remotely initiate software programs installed on 
a Host PC necessary to transfer files and data between 
the Host PC and Remote PC, (3) interconnect (i.e. daisy 
chain) multiple Host Units together so as to allow a Re- 
mote PC to switch between different Host PC's during 
a single access session, and (4) cold boot a Host PC, 
when necessary by instructing the Host Unit to tempo- 
rarily cut the AC power to the Host PC forcing it to per- 
form a cold boot. 

[0030] One embodiment of the present invention 
comprises (1) software installed on the Remote PC that 
permits the Remote PC to utilize a standard modem 
such as, for example, a Hayes 9600 baud Ultra modem, 
Hayes 2400 Smart modem or Boca 14.4 for Modem 
Linkage, or a direct cable connection for Direct Line 
Linkage, to remotely access a Host Unit, thereby allow- 
ing the Remote PC to communicate with the Host Unit 
and access/control a Host PC attached to the Host Unit; 
(2) a Host Unit, which is either (a) directly attached to a 
modem or remote PC or (b) connected to a Remote PC 
via another Host Unit (i.e. daisy chained) and is directly 
connected to the keyboard input, optional mouse input, 
VDAC raster output and AC power input interfaces of 
the Host PC; (3) software program files installed on the 
Host PC that may be activated remotely to facilitate file 
transfers between the Host and Remote PCs and (4) 
software programs run on the Host PC during installa- 
tion to permit the Host Unit attached to the Host PC to 
automatically train itself how to decode the specific vid- 
eo raster output signals from the Host PC's VDAC. 
[0031] Software installed on the Remote PC permits 
(1) accessinjg a Host PC site in either a Modem Linkage 
or Direct Line Linkage mode, (2) initializing a modem 
attached to the Remote PC (including baud rate, and 
initialization strings) necessary for a Modem Linkage 
mode, (3) maintaining a list of Host Units that may be 
accessed from the Remote PC (including the dialing in- 
formation needed to call the Host modem that is used 
to access each Host Unit (when in a Modem Linkage 
mode), the ID number for each Host Unit, and the pass- 
word needed to access each Host Unit), (4) completing 
.a Modem or Direct Line Linkage from the Remote PC to 
a designated Host Unit, (5) displaying status information 
relating to a active connection on the Remote PC's VDM 
screen, (6) scanning the Host PC's VDM screen display 
history transferred from the Host Unit and stored on a 



mass storage device on the Remote PC, (7) setting the 
specific procedure to be used by the active Host Unit to 
capture Host PC VDAC video raster output (i.e. text 
modes, graphic modes, etc. in either monochrome or 

5 color), (8) switching the Remote PC's keyboard and/or 
mouse from use as a normal Remote keyboard and/or 
mouse to use as the keyboard and/ormousefortheHost 
PC, (9) accessing a Host PC for purposes of viewing a 
Host PC's VDM activity without switching the Host PC's 

10 keyboard and/or mouse to the Remote PC's keyboard 
and/or mouse, (10) switching the keyboard and/or 
mouse back from use as Host PC keyboard/mouse to 
use as a Remote keyboard/mouse, (11) initiating and 
controlling the transfer of data files between the Host 

is and Remote PC, (12) communicating with the Host Unit 
using either standard telephone lines and modem com- 
munication protocols, when in a Modem Linkage mode, 
or a direct dedicated line, when in a Direct Line Linkage 
mode, (13) switching the Remote PC's VDM screen 

20 from a normal (i.e. Remote) VDM screen mode to a Host 
screen mode where a Host PC's VDAC output data is 
captured (without Host PC CPU support) and transmit- 
ted by the Host Unit to the Remote PC and is displayed 
on the Remote PC's VDM screen in place of the normal 

25 Remote PC's VDM screen display, (14) switching the 
Remote PC's VDM screen back from a Host PC video 
display to use as a Remote PC video display, (15) noti- 
fying the Host Unit to temporarily cut AC power input to 
the Host PC thereby forcing the Host PC to re-start, 

30 which is commonly referred to in the trade as a "cold- 
boot," (16) switching between Host Units and the Host 
Unif s associated Host PC in cases where more than 
Host Unit is interconnected, (17) changing a Host Unit's 
permanent or temporary password used by Remote 

35 PC's to access the Host Unit so as to prevent the unau- 
thorized access of a Remote user to a Host PC, (18) 
terminating a Modem Linkage or Direct Line Linkage to 
a Host, (19) initiating a connection to another site, as 
required, (20) storing procedures necessary to train a 

40 Host Unit to decode a particular Host PC's VDAC video 
raster output signal, so that such procedures can be re- 
loaded by a Remote PC into the Host PC's memory to 
facilitate using one Host Unit to access more than one 
Host PC without the need to repeat on-site training, and 

45 (21) exiting Remote PC application processing when 
there is no longer a need to access Host PCs. 
[0032] A Host Unit can connect (via cable and adapt- 
ers) to a Host PC and is capable of (1 ) verifying a remote 
user's password entered to access the Host Unit, so that 

50 access to the Host PC will be denied in cases where an 
invalid password is received; (2) permitting a Remote 
PC to optionally take over the Host PC's keyboard and/ 
or mouse by ignoring any input from the Host PC key- 
board and/or mouse and accepting only keyboard and/ 

55 or mouse input from the Remote PC's keyboard re- 
ceived through a Modem Linkage or Direct Line Link- 
age; (3) permitting a user located at a Host site to take 
back control of a Host PC's keyboard and/or mouse by 
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depressing a momentary switch button on the Host Unit; 

(4) passing though the Host PC's keyboard and/or 
mouse input signals to the Host PC via input and output 
keyboard and/or mouse connectors on the Host Unit; 

(5) intercepting, storing, analyzing, decoding and then 
passing through the Host PC's VDAC video raster signal 
to the Host PC's VDM screen display via input and out- 
put video connectors on the Host Unit, even in cases 
where a Remote PC is not accessing the Host unit; (6) 
decoding the Host PC's VDAC video raster output sig- 
nals to either text or bit-mapped graphics format; (7) 
identifying and storing, as necessary, VDAC data that 
has changed between each VDAC refresh cycle; (8) 
compressing, transmitting and storing the changes in 
text or graphics data decoded from the VDAC raster out- 
put signal of the Host PC to a Remote PC; (9) supplying 
input/output interface cable receptacles to permit Host 
Units to be daisy chained with each other so as to allow 
a Remote PC to switch between, and remotely control, 
multiple Host PC's over a single phone line and modem 
during a single phone call; (1 0) supplying AC power to 
the Host PC, through an AC output connector, so as to 
permit the Host Unit, when desired, to temporarily cut 
power to a Host PC forcing the Host PC to reboot. 
[0033] VDAC video raster output signals from a Host 
PC's VDAC circuits may vary from PC to PC (or adapter 
circuit to adapter circuit) making it impossible to utilize 
a standard process to decode the signal. During instal- 
lation of the Host Unit, software supplied with the appa- 
ratus may be activated on the Host PC to train the Host 
Unit to properly decode the text mode VDAC video 
raster output of the Host PC. During this one time train- 
ing process, predetermined text and character strings 
are displayed using software supplied with the Host Unit 
via the Host PC's VDAC. The resulting video raster out- 
put signal of the PC's VDAC is then analyzed by the Host 
Unit's processors to determine the exact procedures 
needed to convert the VDAC raster output signals to 
known text data or graphics pixel data displayed during 
the training process. The results of this training process 
yields the specific procedures and data needed to de- 
code and capture text data or graphics pixel data from 
the VDAC output of a specific PC. Such procedures and 
data are stored in non-volatile RAM contained in the 
Host Unit, so that the training process for a specific Host 
PC need not be repeated unless the Host PC's VDAC 
is changed. This training process permits the Host Unit 
to interface with any of the PC monochrome or color 
VDAC standards, such as CGA, EGA, or VGA familiar 
to persons in the trade. On request by a Remote PC said 
training procedures needed to decode a given Host PC's 
VDAC signal may be copied to a file on a mass storage 
device connected to the Remote PC. This procedure 
would then permit the Remote PC to reset the decode 
procedure used by a Host Unit to support situations 
where a single Host Unit at a site is switched between 
different PC's by user's on site to facilitate remote diag- 
nostics of a PC that has failed. 



[0034] A less preferred embodiment of the present in- 
vention could be employed in which the video capture 
function of the Host Unit is accomplished by inserting 
an adapter card into one of the I/O buss adapter slots 

5 in the PC. This adapter card would have ifs own micro- 
processor, or other processing circuitry, that would in- 
dependently capture and store a PC's Basic Input Out- 
put System (BIOS) video data for transmission to the 
Host Unit over a cable interface from the adapter card 

10 to the Host Unit. There are several reasons why this em- 
bodiment of the present invention is less preferred: 

A. Many PC's now operate in a graphics VDM 
screen mode as opposed to a text VDM screen 

is mode where data is displayed through the PC's in- 
ternal BIOS (Basic Input/Output System) by setting 
pixels on a VDM screen as opposed to sending 
standard character format data to the VDM screen. 
The Windows™ operating system developed by Mi- 

20 crosoft Corporation is an example of a such a 
graphics user interface software operating system. 
In a graphics VDM screen mode numerous VDM 
standards exist that define number, placement and 
intensity options available for displaying graphics 

25 information on the VDM screen. Software drivers 
from the various PC application manufactures may 
modify or circumvent traditional BIOS functions to 
display data on the VDM screen. As the result, the 
process of decoding graphics information at this 

30 level is more diversified and subject to more change 
than the preferred embodiment of decoding the ac- 
tual VDAC video raster output signal which con- 
forms to a relatively fixed standard (i.e. the input to 
a VDM). 

35 b. Some PC's have motherboards with "built-in" vid- 
eo circuitry on the motherboard, which may not per- 
mit tlae userto disable video processing and/or may 
not pass video data across the PC's buss. . 
C. Inserting an adapter card into a PC requires shut- 

40 ting off the PC'spowerthen opening the PC to insert 
the adapter card. Such a procedure is not viewed 
as acceptable to the user as simply attaching inter- 
face cables from the Host Unit to the VDAC inter- 
face port on the PC. Moreover, opening the PC to 

45 install the adapter card would make it difficult and 
time consuming for unskilled personnel at an off- 
site location to setup a spare Host Unit on a failed 
Host PC for remote diagnostic and/or repair by a 
off-site maintenance operation. 

50 D. The size of the PC adapter card must remain 
within fixed size limits. Such limits could constrain 
the level of functionality that could be incorporated 
into the card. 

E. The I/O buss adapter slot, power, etc. within the 
55 Host PC could fail which would prevent the Host 

Unit from transferring any stored video data from 
the Host PC. 

F. An additional adapter card is required, which may 



6 



11 



EP 0 740 811 B1 



12 



preclude users without an available buss adapter 
slot from installing the apparatus. 

[0035] A second less preferred embodiment similar to 
that discussed above, could be used where a dual func- 
tion video I/O adapter card could be engineered and in- 
serted in a PC's I/O buss adapter slot in place of the 
PC's existing video I/O board. One function of this 
adapter card would be to provide video output to a VDM 
screen using standard video connector plugs. The other 
function of the adapter card would be capture the video 
BIOS data using additional circuitry on the I/O adapter 
card and transmit this data to a remote PC. In this case, 
the video adapter card would conform to standard, pre- 
defined video display options and thereby avoid the dif- 
ferent drivers and display approaches taken by the var- 
ious video adapter card manufacturers. There are sev- 
eral reasons why this preferred embodiment of the 
present invention is less preferred: 

A. Inserting an I/O buss adapter card into a PC re- 
quires shutting off the PC's power and then opening 
the PC to insert the card. Such a procedure would 
not be as acceptable for the user as simply attach- 
ing interface cables from the Host Unit to the VDAC 
interface port on the PC. Moreover, opening the PC 
to install the adapter card would make it difficult and 
time consuming for unskilled personnel at an off site 
location to setup a spare Host Unit on a failed Host 
PC for remote diagnostic and/or repair by a off site 
maintenance operation. 

B. Some PC's have motherboards with "built-in" vid- 
eo circuitry on the motherboard, which may not per- 
mit the user to disable video processing and/or may 
not pass video data across the PC's buss. 

C. The size of the adapter card must remain within 
fixed size limits. Such limits could constrain the level 
of features that could be incorporated into an adapt- 
er card with dual functionality. 

D. The I/O buss adapter slot, power, etc. in the Host 
PC could fail which would prevent the Host Unit 
from transferring any video data from the Host PC. 

[0036] Other less preferred embodiments of the 
present invention could also be employed where one, 
several, or all of the remaining functions of the Host Unit 
could be placed on one or more adapter cards using an 
approach similar to that discussed above for other less 
preferred embodiments of the present invention. For ex- 
ample, a special adapter cable could be connected to 
the end of a keyboard cable's plug and plugged into an 
input jack of a keyboard interface adapter card. Then, 
another adapter cable could be plugged into a output 
jack of the keyboard interface adapter card and the other 
end of the cable plugged into the normal input keyboard 
plug on the PC. The keyboard adapter card would con- 
tain a microprocessor and circuity designed to perform 
the keyboard processing function described above for 



the Host Unit. There are several reasons why this pre- 
ferred embodiment of the present invention is less pre- 
ferred: 

5 A. The multiple interface boards would be more 
costly to design and would require the production 
of non-standard interface cables. 

B. Some PC's have motherboards with "built-in" vid- 
eo circuitry on the motherboard, which may not per- 

10 mit the user to disable video processing and/or may 
not pass video data across the PC's buss. 

C. Inserting an I/O buss adapter card into a PC re- 
quires shutting off the PC's power and then opening 
the PC to insert the card. Such a procedure would 

is not be as acceptable for the user as simply attach- 
ing interface cables from the Host Unit to the various 
interface ports on the PC or on other Host Units. 
Moreover, opening the PC to install the adapter card 
would make it difficult and time consuming for un- 

20 skilled personnel at an off site location to setup a 
spare Host Unit on a failed Host PC for remote di- 
agnostic and/or repair by a off site maintenance op- 
eration! 

D. The size of a adapter card must remain within 
25 strict size limits. Such limits could constrain the level 

of functionality that could be incorporated into the 
card. 

E. Multiple adapter cards may be required, which 
may preclude users with insufficient available buss 

30 adapter slots from installing the apparatus. 

F. The I/O buss adapter slot, . power, etc. in the Host 
PC could fail which would prevent the functions now 
being performed by the Host Unit from being per- 
formed within the Host PC's adapter card(s). 

35 

[0037] From the above, it will be readily seen that one 
aspecfeof the present invention is to allow a user at a 
first location to view information displayed on a video 
display terminal, or monitor, of a data processing device 

40 at second location. 

[0038] Yet another aspect of the present invention is 
to allow a user to view the information on the video dis- 
play terminal even if the data processing device at the 
second location is locked up and no longer processing 

45 data or input commands. 

[0039] A still further aspect of the present invention is 
to allow the user at the first location to give commands 
to the data processing device at the second location in 
such a manner that the data processing device per- 

50 ceives the commands as coming from a standard input 
device typically attached to the data processing device 
such as a keyboard or mouse. 

[0040] Another aspect of the present invention is pro- 
vide for the temporary interruption of AC power to the 
55 data processing device at the second location in re- 
sponse to a command from the user to force the data 
processing device to initiate a cold boot, or power on 
routine. 
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[0041] Yet another aspect of the present invention is 
provide a system and method in which video display in- 
formation contained in a video raster signal output from 
a video display circuit of a data processing device is an- 
alyzed to determine the content of the signal and to con- 
vert the signal into a form suitable for transmission over 
a standard public telephone line or other communica- 
tions network. 

[0042] A still further aspect of the present invention is 
to provide a system and method for training the appa- 
ratus to recognize different display formats that are used 
to transmit information from a video display circuit to a 
video display terminal or monitor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0043] The drawings consist of 7 figures numbered 1 
to 7. Figures that consist of more than one sheet contain 
a unique alphabetic suffix for each sheet. When a figure 
is referred to in it's entirety, the alphabetic suffix is omit- 
ted. A brief description of each figure is as follows: 

Fig. 1 is a functional overview of the invention. 
Fig. 2 is a front external view of the Host Unit. 
Fig. 3 is a rear external view of the Host Unit. 
Fig. 4 is an engineering diagram representing an 
overview of the internal circuitry of the Host Unit. 
Fig. 5 is a block diagram describing the microproc- 
essor based software operating system controlling 
processing occurring jn the Host Unit. 
Fig. 6 is a block diagram describing the process of 
training the Host Unit to recognize text for a specific 
PC. 

Fig. 7 is a block diagram describing the software 
operating on the Remote PC. 
Fig. 8 is illustrates the current protocol used to com- 
municate between a Remote PC and a Host Unit. 
Fig. 9 illustrates an alternative embodiment of the 
present invention implemented on a circuit card 
suitable for insertion into a data processing device. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0044] Fig. 1 is a operational overview of the inven- 
tion. Rectangular objects on this diagram represent 
physical (i.e. hardware) components of the apparatus. 
Dashed rectangular boxes represent groupings of relat- 
ed hardware components at different locations, dashed 
lines represent cables or cords, a solid line represents 
a communications interface (e.g. a telephone line or 
dedicated communications line), a arrow on the end of 
a line represents the direction that data or power flows 
and a line with no arrows indicates that data flows in 
both directions. 

[0045] A PC located at a Remote Site 1 may be used 
to access a Host System 6. The Remote PC 2 may be 
equipped with a VDAC and monitor 3, a keyboard 4 and 
a Hayes compatible Modem 5 familiar to persons in the 



trade to access a remote site via a Modem Linkage. No 
modem is necessary to access a Host Unit in cases 
where a Direct Line Linkage is used instead of a Modem 
Linkage. A Mouse 4A may also be connected to the Re- 
5 mote PC. 

[0046] Software installed in the Remote PC 2, permits 
the Remote PC to initiate a call via the Remote PC's 
Modem 5 to a Host Site's Modem 7 over a standard 
phone line or to make a direct linkage via a dedicated 
10 Direct Line Linkage. The apparatus currently supports 
up to 1 9.2kb data transfer rates between a Remote PC 
1 and Host System 6 or between a Host Unit 8 and an- 
other Host Unit 13 or 1 8, but the speed of data transfer 
could be higher or lower and still fulfil the objects of the 
is invention. 

[0047] Host Units 8, 13, 18 may be daisy chained to- 
. getherto permit a Remote PC to switch between Host 
Units during a single access session. A group of Host 
Units connected together on a single daisy chain is here- 
to in referred to as a "Host Site." Software provided with 
the apparatus permits a Remote PC to access more 
than one Host Site, but, presently access to one Host 
site must be terminated before a different Host site may 
be accessed. 

25 [0048] Host Units 8, 13, 18 are identified by a unique 
number set by DIP switches located in each Host Unit. 
There are a total of six DIP switches in a Host Unit avail- 
able to set a specific Host Unit ID number, so the Host 
Unit ID may be set by a user to yield a decimal number 

30 between 00-63 depending on the positions of the switch- 
es. Of course, additional switches could be provided to. 
allow for addressing of a greater number of Host Units. 
. Presently, Host Unit 00 8 must be connected to the Mo- 
dem interface 7 via a modem cable from "Data In" 70 

35 (shown in Fig. 3) receptacle of the Host Unit to the serial 
interface receptacle on the modem or must have a Di- 
rect Line4-inkage via a dedicated cable from the "Data 
In" 70 (Fig. 3) receptacle of the Host Unit to a serial in- 
terface port on the Remote PC. An RJ-1 2 cable with se- 

40 rial port interface cable adapters can be used for either 
purpose. Although any suitable cable could be used, the 
RJ-1 2 cable has six conductors, two of which are avail- 
able for serial communications. Other Host Units may 
then be connected in a Daisy Chain fashion using a ca- 

45 ble from the "Data Our 71 (Fig. 3) receptacle on the last 
Host Unit in the Daisy Chain 13 to the "Data In" 70 (Fig. 
3) of the newly connected Host Unit 1 8. Host Units con- 
nected together in a daisy chain presently use RJ-1 2 
cable for the connection from Host Unit to Host Unit, but 

50 any cable could be used with the appropriate conductors 
therein. In order for a Remote PC to communicate with 
a specific Host Unit on a daisy chain, each Host Unit 
must have a unique ID number assigned from 01 to 63. 
All data packets sent from the Remote PC to a particular 

55 Host Unit on a daisy chain use the Host Unit ID to ad- 
dress the transmitted data packet to a specific Host Unit 
number for a response. Presently, a Remote PC may 
only access one Host Unit at a time, but may switch been 
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Host Units during a single active communications ses- 
sion. 

[0049] A Host Unit 8 receives if s power from an AC 
electrical power source via an AC power cord connected 
to an "AC Power" 61 (Fig. 3) receptacle on the Host Unit. 
The Host Unit also supplies AC power to the Host PC 
10 to which it is connected through an AC power cord 
going from the "AC To PC" 62 (Fig. 3) receptacle on the 
Host Unit to the AC power supply input on the Host PC. 
By supplying power to the Host PC in this manner, AC 
power to the Host PC may be temporarily cut by the Host 
Unit when instructed by a remote user's Remote PC to 
force a locked-up Host PC to cold-boot, so that normal 
Host PC processing can be restored remotely. This 
"cold-boot" procedure is particularly useful when the 
Host PC will no longer respond to any keyboard or other 
input. The Host PC is turned off and back on by the re- 
mote user, thereby reinitializing the Host PC's process- 
ing circuitry. 

[0050] When a Host Unit 8 is first connected to a Host 
PC 10, the Host PC's keyboard 1 1 is disconnected from 
the keyboard input jack and plugged into a "Keyboard 
Input From KB" 68 (Fig. 3) receptacle on the Host Unit. 
Then, a Keyboard Cable supplied with the apparatus is 
plugged into the "Keyboard Output To PC" 69 (Fig. 3) 
receptacle on the Host Unit and the other end of this 
cable is plugged into the keyboard input jack on the Host 
PC. In this manner, the keyboard's signals go through 
Host Unit to the Host PC, which permits the Host Unit 
to interrupt Host keyboard signals and redirect keyboard 
input to utilize the Remote PC's keyboard instead of the 
Host PC's keyboard. Therefore, a Host PC need not 
have a Keyboard 11 present in order to facilitate Key- 
board 4 data input and control of the Host PC by a Re- 
mote PC. With regard to the Remote PC's Keyboard 4, 
when the Remote PC 2 is accessing a Host Unit, the 
Remote PC's keyboard input is also captured by a soft- 
ware program running on the Remote PC supplied with 
the apparatus and redirected out of the Remote PC to 
the Host Unit 8 for input into the Host PC 10 via either 
a Modem (5 to 7) or Direct Line Linkage (2 to 8). 
[0051] Similarto keyboard cabling, the Host PC's vid- 
eo cable from the Host PC's video display 9 (VDM) is 
disconnected from the Host PC's VDAC and plugged in- 
to either the Host Unit's 8 15 pin "VGA Out" 64 (Fig. 3) 
or 9 pin "Video Our 66 (Fig. 3) receptacle depending on 
the number of pins on the video cable's connector. Then , 
either the corresponding 9 pin or 1 5 pin video cable sup- 
plied with the apparatus is plugged into the appropriate 
15 pin "VGA In" 65 (Fig. 3) or 9 pin "Video In" 67 (Fig. 
3) receptacle on the Host Unit 8 and the other end of the 
video cable is plugged into the Host PC's video display 
9 (VDAC). This configuration allows the Host PC's video 
display 9 (VDAC) output signals, including the video 
raster signals, to pass through the Host Unit 8, so that 
the Host Unit can access, scan and decode the signals 
into either bit image, or monochrome or color text data 
and also store the most recent data (up to the internal 



storage capacity of the Host Unit) for transmission to a 
Remote PC when requested. 

[0052] A serial cable. can be connected from one of 
the Host PC's communications ports to a "Serial" 72 
5 (Fig. 3) receptacle on the Host Unit 8. This connection 
permits data file transfers to occur between a mass stor- 
age device on a Remote PC 2 and the Host PC 10. This 
connection also permits data from a Remote PC's 
Mouse 4A to be transmitted to the Host PC's serial port 
10 through the Host Unit's Serial 72 (Fig. 3) interface. 
Mouse input 4A from a Remote PC is captured by soft- 
ware running on the Remote PC (supplied with the ap- 
paratus) and redirected out of the Remote PC 2 to the 
Host Unit 8 for input into the Host PC 10. 
15 [0053] When a Host Unit 8 is first connected to a Host 
PC 10, the Host PC's serial Mouse 11 A (if present) is 
disconnected from the Host PC's serial port and plugged 
into a "Mouse" 73 (Fig. 3) receptacle on the. Host Unit. 
This permits Mouse 11 A signals to pass through Host 
20 Unit to the Host PC via the "Serial" 72 (Fig. 3) port in- 
terface on the Host Unit 8. This approach permits the 
Host Unit 8 to interrupt any Host PC Mouse 11 A input 
signals and redirect mouse data input to utilize the Re- 
mote PC's Mouse 4A instead of the Host PC's Mouse 
25 11 A. On this basis, a Host PC need not have a Mouse 
11 A present in order to facilitate Mouse 4A data input 
and control of the Host PC by a Remote PC. A mouse 
interface could exist on any Host Unit on a daisy chain 
(e.g. Host Unit 01 13, Unit.. 18, etc.). 
30 [0054] A microprocessor and software located in each 
Host Unit on a daisy chain 8, 13, 18 looks for communi- 
cation data packets sent from a Remote PC addressed 
individually to the Host Unit's ID number. When re- 
ceived, codes contained in the data packet define the 
35 nature of a Remote PC's processing request. For exam- 
ple, a data packet may contain a code requesting the 
Host Unit to verify that a password contained in the 
packet is correct. If the password is correct, the Host 
Unit transmits a data packet back to the Remote PC with 
^0 a code indicating the password had been verified. Oth- 
erwise, a data packet containing a code indicating that 
the password was Incorrect is returned to the Remote 
PC. Similar data packet requests and responses would 
be sent over the communication tine interfaces for other 
^5 remaining functions of the system. 

[0055] A second microprocessor, memory storage 
and software also exists in each Host Unit. The primary 
purpose of this microprocessor and related operating 
system software is to capture, decode, store and trans- 
50 rnit individual Host PC VDAC data to a Remote PC. Al- 
though the most preferred embodiment of present in- 
vention contains two microprocessors to handle the vid- 
eo analysis and the communications with a remote PC, 
it is contemplated that these functions could be per- 
55 formed by a single microprocessor having sufficient 
computing power to conduct both operations. Notably, 
as microprocessor technology continues to evolve, it is 
possible that a single processor system could be devel- 
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oped, thereby increasing reliability and reducing costs. 
[0056] Host System 01 12 and Host System.. 17 rep- 
resent examples of how other Host Unit/Host PC con- 
figurations can be daisy chained at a site, so that one 
Modem or Direct Line Linkage could be used to permit 
a Remote PC to switch between multiple Host Units dur- 
ing a single communications session. The in the 
"Unit.. "and n Host System.." identifiers on Fig. 1 are used 
to indicate one or more additional Host Units may exist 
on the daisy chain. The maximum number of Host Units 
depends on the available number of bits used for each 
Host Unit address, and the most preferred embodiment 
supports up to 64 Host U nits at any one Host Site. These 
other Host System configurations are connected to their 
respective Host PCs in the same manner as described 
above for Host Unit 00 8. More specifically, Host Unit 01 
13 and Host Unit. 18 are connected to video displays 
15, 19; Host PCs 16, 20; and Keyboards 17, 21 using 
the same procedures described for Host Unit 00 8 
above, except the last Host Unit in the daisy chain would 
not have a daisy chain cable connected to the Host 
Unit's "Data Out" 71 (Fig. 3) receptacle. Software in- 
stalled on a Remote PC (provided with the apparatus) 
permits a Remote PC to access more than one Host 
Site, but access to one Host site must be ended before 
access to another Host site can begin (i.e. no more than 
one Host Site may be accessed at a time). 
[0057] Fig. 2 details a frontal view of a Host Unit. The 
front panel of the Host Unit includes five status indicator 
lights 50-54 and an "Action" momentary switch 55. All 
five indicator lights will be off until the ON/OFF power 
switch, located on the right rear side of the Host Unit is 
turned ON . A detailed description of the purpose of each 
of the five indicator lights going from left to right is as 
follows: 

AC Power 50 - This light indicates that the Host 
Unit's on/off switch is in the "on" position and AC 
power is being received into the Host Unit. 
Keyboard Local 51 - This light indicates the key- 
board/mouse attached to the Host Unit is available 
for use. 

Keyboard Remote 52 - This light indicates a remote 
user is accessing the Host Unit. If the light is blink- 
ing, it means a remote user is in the process of con- 
necting to the Host Unit or has been previously 
blocked by a Host PC user from taking over the key- 
board. If the light is ON, it means a remote user has 
taken over the Host PC's keyboard and/or mouse. 
Daisy Chain 53 - This light presently blinks period- 
ically indicating a remote user is currently connect- 
ed to one of the Host Unit's on the daisy chain. If no 
remote user is accessing a Host Unit on the daisy 
chain, the light will be off. 

Setup Mode 54 - This light blinks during the initial 
training or re-configuration of the Host Unit to indi- 
cate the Host Unit is properly linked to the Host PC. 
This light also blinks when file transfers are occur- 



ring between a Remote PC and Host PC. 

[0058] If someone is using a Host PC's keyboard and/ 
or mouse when a Remote PC attempts to take over the 
5 Host PC, a user at a Host PC site may" wish to retain 
control of the Host PC's keyboard and/or mouse by de- 
pressing the Action 55 momentary switch. Only one user 
can have control of the Host PC's keyboard and/or 
mouse at any point in time. In cases of conflict, the user 

10 at the Host site has the final authority to determine who 
controls the Host system's keyboard and/or mouse. 
Control may be passed back and forth by depressing 
the Action 55 momentary switch. Regardless of who has 
current control of the Host Unit's keyboard and/or 

*5 mouse, a remote user will have the ability to view the 
Host PC's VDM screen remotely on their Remote PC 
after they have successfully connected to a Host Unit. 
Such VDM screen access can be prevented by a Host 
user by turning the Host Unit's ON/OFF switch OFF. 

20 [0059] As previously mentioned, the Keyboard Re- 
mote 52 light on the front of the Host Unit indicates a 
remote user is accessing the Host Unit. If the light is 
blinking, it means a Remote PC is in the process of ini- 
tially accessing the Host Unit or has been previously 

25 blocked by a Host PC user from taking over the Host 
PC's keyboard. If the light is ON, it means a remote user 
has taken over the Host PC's keyboard and/or mouse. 
When a remote user initially attempts to take over a Host 
PC, a brief audible alarm sound is generated from a 

30 speaker (not shown) within the Host Unit to further alert 
anyone present at the Host Site that the Host Unit's key- 
board and/or mouse is about to be taken over by a Re- 
mote PC. 

[0060] While the Keyboard Remote 52 light is flash- 
es ing, another user at the Host PC may depress the Action 
55 momentary switch on the front panel to prevent a Re- 
mote PC4rom taking over the Host PC's keyboard and/ 
or mouse. If the Action 55 momentary switch is de- 
pressed for this purpose, the Keyboard Remote 52 light 
40 will continue to flash and the remote user will be pre- 
vented from taking over the Host PC's keyboard and/or 
mouse until either the Action 55 momentary switch is 
depressed again or the remote user disconnects and re- 
connects at a later time. If the remote user should dis- 
45 connect from the Host Unit while the Keyboard Remote 
52 indicator is flashing, the indicator will turn off auto- 
matically. When a remote user is blocked from access- 
ing a Host Unit's keyboard and/or mouse, they will re- 
ceive an alert message on their VDM screen (cc - - :cted 
50 to the Remote PC) during the connection proce': Hven 
if a Remote user is prevented from accessing a - key- 
board and/or mouse by persons present at the Host 
Unit, the remote user will stili be able to monitor any 
VDM screen activity on the Host PC. Once a user has 
55 taken over a Host keyboard, the Keyboard Remote 52 
indicator light will remain on. The remote user's privilege 
to continue to use the Host PC's keyboard and mouse 
can be revoked at any time by depressing the Action 55 



10 



19 



EP 0 740 811 B1 



20 



momentary switch on the front of the Host Unit, which 
causes the Keyboard Remote indicator light to blink until 
the remote user disconnects from the Host Unit. When 
such an action. is taken, the remote user will remain 
locked out until either the Action 55 momentary switch s 
is depressed again or the remote user terminates the 
connection and reconnects at a later time. 
[0061] In cases where a Remote User desires access 
to a Host Unit in a manner that would not be readily de- 
tectable by anyone using the Host PC (hereinafter re- 10 
ferred to as a "stealth mode"), the embodiment of the 
Host Unit could only include AC Power 50 and Setup 
Mode 54 lights and would not include the audible alarm. 
In such cases, the Remote user would access the Host 
Unit in a "view only" mode, as more fully described be- 15 
low in the narrative supporting Fig. 5B. This embodi- 
ment would be used, for example, in cases where an 
employer desired to remotely, discreetly, monitor em- 
ployee use of an employer's Host PC. 
[0062] Fig. 3 details the present rear view of the Host 20 
Unit. A variety of alternative interface cables, adapters 
and connectors could have been used to connect v the 
Host Unit to the Host PC, modem (Modem Linkage 
mode), Remote PC (Direct Line Linkage mode), and/or 
another Host Unit on a daisy chain. For example, the 25 
Rj-12 receptacle presently used to connect the Host 
Unit's serial output to the Host PC's serial input could 
have used a 25 pin female receptacle and a parallel in- 
terface cable from the Host Unit to one of the parallel 
ports on the Host PC. As a second example, standard so 
serial cables and serial receptacles could have been 
used in place of the RJ-12 receptacles to connect the 
Host Unit to a modem/Remote PC and to connect Host 
Units together on a daisy chain. Such alternative ca- 
bling, connector and receptacle approaches are known 35 
to persons familiar with the trade and do not materially 
affect the functioning of the apparatus. 
[0063] The rear panel of the Host Unit presently con- 
tains the AC power receptacles, various RJ-12 data 
transfer linkage jacks, various video interface recepta- *o 
cles, keyboard interface ports, optional mouse interface 
ports and user replaceable fuse with a fuse blown indi- 
cator light. A detailed description of each item on the 
back panel going from left to right is as follows: 

45 

ON/OFF Switch 60 - The ON/OFF power switch 60 
is used to turn off AC power input into the Host Unit. 
Turning this switch ON or OFF controls only power 
flowing to the internal circuitry of the Host Unit and 
has no effect on AC power flowing to the Host PC. 50 
AC Power 61 - The female end of the AC power cord 
used that is normally used by the Host PC to obtain 
AC power is plugged into this receptacle and the 
other three-prong male end of the cord is plugged 
into a source for AC power such as a public utility 55 
wall outlet or a battery backup system. This cord 
would then carry AC power into the Host Unit. 
AC To PC 62 - One end of the AC power cord sup- 



plied with the apparatus is plugged into this recep- 
tacle and the other end of the power cord is plugged 
into the AC power input of the Host PC, so that the 
Host PC depends on the Host Unit for it's AC power, 
This approach permits the Host Unit to satisfy a re- 
quest to cold-boot the Host PC by temporarily cut- 
ting off AC power to the Host PC. The power can 
be interrupted for any suitable time to allow the Host 
PC to properly re-boot, for example from approxi- 
mately 1 to 30 seconds. In the preferred embodi- 
ment this time is approximately 15 seconds. 
Fuse 63 - The system employs a user replaceable 
5 amp / 250 volt fuse on the rear panel with an in- 
dicator light which lights when the fuse is blown. 
When the fuse is blown power to the Host PC will 
be terminated. 

Fuse Light 63A - When AC power is applied to the 
Host Unit and the Fuse 63 is blown, this indicator 
light will be ON. 

VGA Out 64 - For Host PC's with a VGA graphics 
VDAC, the 15 pin connector from the end of the 
Host PC's VDM cable is plugged into this recepta- 
cle. This receptacle permits the signal received 
from Host PC's VDAC through the VGA In 65 recep- 
tacle to be passed out to the Host PC's VDM. . 
VGA In 65 - For Host PC's with a VGA mode VDAC, 
one end of the 15 pin male to male VGA video in- 
terface cable (supplied as part of the apparatus) is 
. plugged into this receptacle and the other end of the 
cable is plugged into the Host PC's VDAC recepta- 
cle. This cable interface permits the Host Unit to 
capture the video output signal from the Host PC's 
VDAC and pass the signal out through the VGA Out 
64 receptacle to the Host PC's VDM. 
Video Out 66 - For Host PC's with other than a VGA 
graphics card, the 9 pin connector from the end of 
the=Host PC's video monitor cable is plugged into 
this receptacle. This receptacle permits the signal 
received from Host PC's VDAC through the Video 
In 67 receptacle to be passed out to the Host PC's 
VDM. 

Video In 67 - For Host PC's with other than VGA 
mode VDACs, the female end of the 9 pin female 
to male video interface cable (supplied as part of 
the apparatus) is plugged into this receptacle and 
the other male end of the cable is plugged into the 
Host PC's VDAC receptacle. This cable interface 
permits the Host Unit to capture the video output 
signal from the Host PC's VDAC and pass the signal 
out through the Video Out 66 receptacle to the Host 
PC's VDM. 

Keyboard Input From KB 68 - The Host PC's key- 
board cable is plugged into the Keyboard Input 
From KB receptacle instead of into the PC's key- 
board input receptacle. This permits the Host Unit 
to pass or block any Host keyboard input to the Host 
PC, as required. 

Keyboard Output To PC 69 - One end of the male 
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to male keyboard interface cable (supplied as part 
of the apparatus) is plugged into this receptacle and 
the other end of the cable is plugged into the Host 
PC's keyboard input receptacle. This receptacle is 
used by the Host Unit to transfer keyboard input 5 
from either the Remote or the Host PC's keyboard 
to the Host PC. 

Data In 70 - One end of a telephone style RJ-12 (6 
wire) cable (supplied as part of the apparatus) is 
plugged into this receptacle and the RJ-12 jack on 10 
the other end of the cable is connected to either the 
Data Out 71 jack of another Host Unit or to either 
(1 ) an external, stand alone, Hayes compatible mo- 
dem for a Modem Linkage mode or (2) a Remote 
PC's data transfer interface port for a Direct Line 15 
Linkage mode. When a Host Unit is connected to 
another Host Unit via a daisy chain, at least one of 
the Host Units on a daisy chain must be connected 
to a modem (Modem linkage mode) or directly con- 
nectedto a Remote PC (Direct Line Linkage mode). 20 
The modem connection can be accomplished by 
plugging the open end of the telephone cable into 
the telephone jack-to-9 pin male adapter plug (sup- 
plied with the apparatus), and then plugging the 9 
pin male adapter into the data interface receptacle 25 
on the modem. If the modem has other than a fe- 
male 9 pin receptacle, then gender changers and/ 
or 9 pin to 25 pin adapters (available for the appa- 
ratus) must be used to complete the Unit-to-modem 
connection. The Remote PC Direct Line Linkage 30 
connection can be accomplished by plugging the 
open end of the telephone cable into the telephone 
jack-to-9 pin female adapter plug (supplied with the 
apparatus), and then plugging the female adapter 
into the data interface receptacle on the Remote 35 
PC. If the Remote PC has other than a male 9 pin 
data interface receptacle, then gender changers 
and/or 9 pin to 25 pin adapters (available forthe ap- 
paratus) must be used to complete the Unit-to-Re- 
mote PC connection. 40 
Data Out 71 - One end of a telephone style RJ-12 
(6 wire) cable (supplied as part of the apparatus) is 
plugged into this receptacle and the other end of the 
RJ-1 2 cable is plugged into the Data In 70 recepta- 
cle of another Host Unit. If this is the last Host Unit 45 
in a daisy chain, no cable would be plugged into this 
receptacle. When a Host Unit is connected to an- 
other Host Unit, at least one of the Host Units on a 
daisy chain must be connected to a modem for the 
Modem Linkage mode or to a Remote PC for the 50 
Direct Line Linkage mode (as described above for 
the Data In 70 receptacle). The Data In 70 and Data 
Out 71 receptacles are also used to transmit data 
packets between a selected Host Unit and a Re- 
mote PC. - 55 
Serial 72 - One end of an RJ-12 cable supplied with 
the apparatus is plugged into this receptacle and 
the other end of the RJ-12 cable is plugged into a 



serial communications port on the Host PC using a 
RJ-12 to serial port adapter plug provided with the 
apparatus. Data file transfer between the Host PC 
and Remote PC occur through this Serial 72 recep- 
tacle. Presently, the apparatus uses serial data 
transfers but transfers are also possible through the 
Host PC's parallel port. 

Mouse 73 - The Host PC's serial mouse cable is 
plugged into the male Mouse receptacle 73 instead 
of into the PC's serial port. This permits the Host 
Unit to pass through or block any Host Mouse input 
to the Host PC, as required. 

Aux 74 - Auxiliary devices may be plugged into this 
receptacle, which is presently an RJ-12 jack, and 
this receptacle permits two way communications 
between the device and the Host Unit. Specific uses 
for this port are discussed later. 

[0064] On the side of the Host Unit there are eight DIP 
switches (not shown). The left most 6 DIP switches in- 
dicate the Host Unit's ID number. When these 6 DIP 
switches are in the down position, the Host Unit is con- 
nected directly to a modem (Modem Linkage mode) or 
to a Remote PC (Direct Line Linkage mode). Otherwise, 
when the Host Unit is daisy chained through other Host 
Units, each Host Unit on the daisy chain must be as- 
signed a unique Dl P switch setting indicating an address , 
from 1 to 63 by the user. On this basis, only a maximum 
of 64 Host Units can be daisy chained at a Host Site. As 
noted above, however, the number of DIP switches 
could be increased to allow additional units to be daisy 
chained together. The 6 DIP switch settings presently 
represent binary values reading from left to right. Ac- 
cordingly, if only the left most DIP switch is set to the up 
position, the Host Unifs ID would be 1 . If the left most 
two DIP switches were set to the up position, the Host 
Unifs ID^ould be 3, (i.e. 1+2) and so forth. In order to 
remotely access a Host Unit, the Host Unit ID number 
must be correctly defined on the remote PC's call table, 
as discussed below under the narrative for Fig. 7. 
[0065] The seventh and eighth DIP switch are acces- 
sible to the Host Unit circuitry. The seventh DIP switch 
is not presently used. The eighth DIP switch is presently 
used for VGA VDAC's to indicate whether a mono- 
chrome (i.e. DIP switch in the UP position) or color (i.e. 
DIP switch in the DOWN position) VGA VDM is connect- 
ed to the VGA OUT 64 receptacle of the Host Unit. 
[0066] Fig. 4A through Fig. 4P illustrate general func- 
tional diagrams of the Host Unit's internal circuitry. Fig. 
4A depicts an overview of the Host Unit's circuitry. The 
unit contains a power supply 100, two microprocessors 
(CPUs) 106, 114, and associated circuitry. 
[0067] The Video CPU 114 controls the video circuitry 
(i.e. blocks 110-113 and 1 1 5), interface to the Host PC's 
Data Circuitry 1 1 6, and interface to the Host PC's Mouse 
Circuitry 117. The Host Data 116 and Mouse Circuitry 
117 interfaces between the Host Unit and Host PC occur 
using the Host PC's serial interface port. However, other 
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Host PC data ports, such as a parallel interface port, 
could have been chosen for this purpose. The Host Data 
Circuitry 116 interface is used to accomplish file trans- 
. fers between a Remote PC and a Host PC. 
[0068] Additional features of the invention discussed s 
below that could be included in the software of the de- 
vice by one of skill the art include mouse processing ca- 
pability, Host PC screen history recordation, files trans- 
fers between a Host PC and Remote PC, password 
lockout protection, temporary password processing, 10 
training parameter up-loading and down-loading, inter- 
nal modem operation, acoustical coupler operation, and 
AUX port operation. 

[0069] The Control CPU 106 controls the Keyboard 
Circuitry 101; Host Unit Front Panel Circuitry 102 and 15 
Remote Data Circuitry 103. The Keyboard Circuitry 101 
passes the Host PC's keyboard signals through to the 
Host PC or alternatively redirects all keyboard signals 
away from the Host PC's keyboard to a Remote PC's 
keyboard (via the Remote Data Circuitry 103) when re- 20 
quested by an authorized remote user. The front panel 
circuitry controls the indicator lights and action button 
located on the Host Unit's front panel (see Fig. 2) as well 
as the Host Unit's audible alarm. The Remote Data Cir- 
cuitry 103 permits digital data to flow between the Host 25 
Unit and a Remote PC and/or other Host Units on a dai- 
sy-chain. This digital data could be transmitted using 
RS-232 serial communication signals familiar to per- 
sons in the trade. This digital data could include, for ex- 
ample, video display data being transmitted from a Host 30 
Unit to a Remote PC, Keyboard input data transmitted 
from the Remote PC to a Host Unit and modem setup 
strings. Also, the Control CPU 106 has access to the 
Host Unit's fixed serial number 104 and Non-Volatile 
(NV <RAM) memory 108. NV RAM 108 is used to store 35 
the critical data needed to be saved in cases where AC 
power to the Host Unit is interrupted, such as, for exam- 
ple, the password(s) needed to access the Unit. 
[0070] The Control CPU 106 and Video CPU 114 
communicate with each other via a two-way data port 40 
107. 

[0071] Presently, the power supply 100 is a linear 
power supply with power transformer, bridge rectifier, fil- 
ter capacitor, and two 7805 5 volt regulators. The power 
control circuitry controls AC power to the Host PC and 45 
in the present implementation is comprised of a 5 amp 
fuse, 5 amp relay and associated driver transistor. The 
driver transistor is controlled by a power lock circuit 1 05 
that prevents inadvertent activation of this circuit, which 
would cause AC power to the Host PC to be temporarily 50 
interrupted. 

[0072] The Keyboard Circuitry 101 interfaces to the 
Host PC and it's keyboard. Referring to Fig. 4B, the Host 
.keyboard signals 122 are comprised of two primary 
lines: CLOCK and DATA which allow bi-directional com- 55 
munication between the keyboard and the Host PC 120. 
Symbols used on Fig. 4B to denote switches, number 
of lines, etc. are familiar to persons in the trade. When 



remote access is not occurring to a Host Unit (i.e. a nor- 
mal local operating mode), the Host PC's keyboard sig- 
nals are routed directly to the Host PC's keyboard input 
receptacle as shown in block 1 21 . When in remote mode 
(i.e. a remote user has taken control of a Host PC's key- 
board input), the Control CPU 106 causes the circuitry 
121 to disconnect the Host PC's keyboard 120 and 
causes the Host PC to receive it's keyboard signals from 
the Control CPU via references 123, 124, 125. The two 
keyboard signals, Clock and Data, (nominally at 5 volts, 
pulled high via resistors) go through an I/O circuit 124 
and 125 which separates them into input and Output 
lines for each signal 126 and shown in more detail at 
block 127. This circuit contains an open collector gate 
142 and a pull-up resister 141 (a nominal 2.2K value 
was used). This allows the Host Unit to emulate a key- 
board signal. References 143 and 144 represent how 
the clock and data signals are split into input and output 
lines connected to the control CPU, 
[0073] The Mouse circuitry 117 (Fig. 4A) is further de- 
tailed in block 131 on Fig. 4B. In local mode, the serial 
mouse signals 132, which could use an RS-232C pro- 
tocol, are passed from the Mouse interface connector 
(see Fig. 3 at reference 73) directly through to the Host 
Unit's serial output (see Fig. 3 at reference 72) to the 
Host PC's serial data port 130, as shown, When in re- 
mote mode, the Host Unit's Video CPU 114 activates a 
switch so that only mouse input data received from the 
Remote PC 133 is passed through to the Host PC's se- 
rial port. In addition, this connection also serves another 
purpose. It allows data files to be transferred between 
the Host PC and Remote PC. The decision as to wheth- 
er mouse data or data files are being transferred is de- 
termined by the software operating system on the Re- 
mote and/or Host PC's. The Host PC treats all serial in- 
put received as mouse data unless a special software 
program, provided as part of the apparatus, is activated 
on the Host PC (via Keyboard commands from the Re- 
mote PC) which will cause the Host PC to treat serial 
input data as data file transfers instead of mouse input 
data. When processing by this software program is com- 
plete, the Host PC will treat any subsequent serial input 
as mouse data. 

[0074] Host units can be connected together as a dai- 
sy-chain using a dedicated cable- to interconnect each 
Host Unit. A modem (or primary serial data line) con- 
nects to the Host Unit Data In receptacle of the Host Unit 
number 00 and the Data Out port of this Host Unit can 
then be connected to the Data In receptacle of another 
Host Unit, and so on as previously described in the nar- 
rative for Fig 1 . 

[0075] The Control CPU 106 contains an 80C32 mi- 
croprocessor, 32K of RAM memory and 32K of EPROM 
memory, but any microprocessor and any amount of 
memory could be used with the invention. The EPROM 
contains the operating system software for this CPU. Al- 
so, the Control CPU 106 has access to an 8 position 
dip-switch. As discussed above, this dip-switch deter- 
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mines the units identification number. This number, or 
address, is used to allow access to a particular Host Unit 
on a daisy-chain by a Remote PC, and addresses may 
be determined by the user. However, Host Unit number 
00 is different and expects a Hayes compatible modem, 5 
or Direct Line Linkage to be connected to the Data In 
port (see Fig 3 at reference 70). 
[0076] As shown in Fig. 4C, the Remote Data Circuitry 
1 03 allows Host Unit access to occur. Data coming from 
the Remote PC 1 50, electrically passes through the Da- 10 
ta In port to the Data Out ports of each Host Unit 151, 
152, 153 on a daisy chain. The Control CPU 151 A, 
1 52A, 1 53A of each Host Unit receives any data passing 
through the daisy-chain from the Remote PC 150 on a 
Receive 155 line. 15 
[0077] Data going from Host Units to a Remote PC is 
on a different transmission line 156 which is separate 
from the Receive 155 line. When no Host Unit on a dai- 
sy-chain is accessed none of the Host Units are electri- 
cally connected to the transmission 156 line. However, 20 
when a Remote PC accesses a Host Unit via the receive 
1 55 line, that Host Unit electrically connects to the trans- 
mission 156 line through a relay 151 B, 152B, 153B to 
facilitate two way communication between the Host Unit 
and a Remote PC. 25 
[0078] AC Power to the Host PC is controlled by a 
power lock circuit 105 (Fig. 4A). This circuit insures that 
an intentional data transfer occurs before the power 
control circuitry 100 will briefly interrupt AC power to the 
Host PC. This "lock" circuitry requires that not only a 30 
specific series of values be written to it, but also at spe- 
cific port addresses, and a separate bit value must be 
correct at the time of writing, before the Host Unit will 
permit AC power to the Host PC to be interrupted. This 
power lock circuit, as well as the video processing cir- 35 
cuitry discussed below, both utilize a Cyclic Redundan- 
cy Check (CRC) function familiar to person of skill in the 
art for processing. 

[0079] As shown in Fig. 4D, CRC is a common proc- 
ess used for generating pseudo-random numbers and *o 
reducing long streams of data to a smaller check sum 
quantity (1 , 2, or more bytes). CRC is typically used for 
random number generation, bit stream identification and 
bit stream error detection. 

[0080] The CRC process is based on shifting the par- 45 
ity, or single bit sum, of an input data signal 185 and 
selected bits 178, 179, 181 of a shift register output 177. 
Each time the shift register 172 is clocked 171, a new 
bit 170 is shifted into the shift register. EXCLUSIVE OR 
gates 180, 182, 184 generate the parity signal. After 8 
clocks, the new value 177 will have no apparent relation 
to the previous value. If the input bit 185 is hard-wired 
to plus (or a logical 1), a long series of pseudo-random 
values can be generated. Rather than hard-wiring this 
input 185, gate 184 would normally be omitted and sig- 
nal 183 would be connected to 170. The series gener- 
ated will repeat every N clock cycles where N has a the- 
oretical maximum of 256 for an 8 bit shift register and 



65,536 for a 16 bit shift register. If a data stream is 
present 185, this will modify the pseudo-random series 
and produce a unique value at 177 which can be used 
to identify the data stream. Note that the particular bits 
173, 174, 176 of the shift register output! 74 selected 
for parity generation determi nes the pseudo-random se- 
ries generated. That is, connections 178 and 179 can 
be connected to different bits of 177, such as the output 
bit referenced at 1 75 and/or more bits can be added with 
more EXCLUSIVE OR gates and the numbers generat- 
ed will be different. 

[0081] Fig. 4E shows a diagram of the power lock cir- 
cuitry. The CRC generator 213 uses an 8 bit shift register 
and is similar to Fig. 4D with the data input 185 omitted 
and a clear input 212 is provided. This clear input will 
set the CRC value to zero. Power to the Host PC is ter- 
minated. when bit latch output 222 is ON. To set this bit 
latch output 222, the Control CPU (in the present imple- 
mentation) generates a write pulse to the bit latch 221 
when the digital signal 223 is a one (logical high). This 
signal 223 is a one (logical high) only when the CRC 
value 1 96 is compared via the compare circuitry 1 98 and 
is equal to the value 1 28 (hexadecimal 80) which is hard- 
wired 197 to this value. Signal 202 will clock the CRC 
generator 21 3 only when the compare output signal 1 90 
is a one (logical high). Otherwise signal 202 will instead 
set the CRC value 196 to zero. This is accomplished by 
logic gates 200, 204, 205. When a CRC output 196 is 
compared with data input 194 via compare circuit 195, 
and is equal, then output 190 will be a one (logical high). 
Assuming the CRC value 1 96 is zero, then approximate- 
ly 250 clock pulses 21 1 occur before the CRC value 1 96 
will reach 128 (80 hexadecimal) during which time the 
CRC generator 213 will have produced approximately 
250 unique CRC values 196. To produce these clock 
pulses 211 the value 194 must be equal to the current 
CRC value 196 for each write pulse 202. This data byte 
input 194 is composed of three sets of signals 191, 192, 
193. The address lines 193 makes this port 194 appear 
as 8 output ports to the Control CPU 106 (Fig. 4A). Thus, 
the Control CPU must correctly set up the lock bit 191 , 
and write (via pulsing at reference 202) a correct value 
1 92 to the correct port 1 93 with the combi nation of these 
signals being equal to the current CRC 1 96 to clock 21 1 
the CRC generator and get the next CRC value. This 
continues until the CRC value becomes 128 (80 hexa- 
decimal) and then the Control CPU pulses 22!0. The 
choice of 191, 192, 192 ensures that the Host PC's AC 
power will not be interrupted inadvertently in the event 
of erroneous processing by the Control CPU. 
[0082] The above circuit is employed in the most pre- 
ferred embodiment of the present invention to ensure 
that power to the Host PC will not be interrupted unless 
commanded by a user. However, if such precautions are 
not warranted, a simpler power management circuit 
could be employed to, for example, reduce the overall 
cost of the system. This circuit could, for example, only 
require that the control CPU 106 receive a power inter- 
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rupt command byte from the remote user. Other exam- 
ples of less complex power management circuits will be 
readily apparent to those of skill in the art in light of the 
above discussion. 

[0083] The Control CPU 106 has access to a serial 5 
number device 104. This provides a unique hardware 
serial numberforthe unit. The preferred embodiment of 
the present invention uses a DALLAS DS2401 part, 
which comes pre-programmed with a unique serial 
number. Of course, other suitable means could be em- 10 
ployed to retain the hardware serial number for each 
Host U nit. Also, the Host Unit includes 2K of non-volatile 
RAM 108 for storage of the unit's password and video 
timing and CRC information peculiar to the Host PC's 
video hardware configuration, which are determined 15 
during a Host Unit training process discussed below in 
connection with Figs. 6A to 6D. 

[0084] In the preferred embodiment, the Video CPU 
114 contains an 80C32 microprocessor, two banks of 
32K by 8 bits of RAM memory (totalling 64K) and 32K 20 
of EPROM memory. This microprocessor, as well as the 
control microprocessor 106 discussed above, could be 
replaced by any suitable microprocessor (for example 
an 80286, 80386, 80486, 68000, 6801 0, etc.) and mem- 
ory. The EPROM contains the operating system soft- 25 
ware for this CPU. An RS-232C serial port 116 is pro- 
vided for file transfers or serial mouse data to the Host 
PC. 

[0085] The portions of the Host Unit which deal with 
video processing employ a combined hardware / soft- 30 
ware approach. In this regard, discrete logic circuitry 
does some of the video processing and a microproces- 
sor and associated operating software performs the re- 
mainder of the video processing. In the preferred em- 
bodiment, this was done to preserve flexibility in the vid- 35 
eo processing techniques. As will be readily apparent to 
those of skill in the art, other embodiments of the inven- 
tion may dedicate more of this processing to discrete 
circuitry, to lessen demands placed on the processing 
software to increase processing performance, or more *o 
of this processing to software or hardware to enhance 
flexibility. 

[0086] The Control CPU 106 and the Video CPU 114 
communicate through a two-way communication port 
107. As shown in Fig. 4F, the Control CPU 106 checks ^ 
the write status 232 to see if the latch 234 is empty. If it 
is empty, the CPU presents a value 230 and toggles the 
write line 231. This will set the bit latch 236 and the sta- 
tus 232 will indicate that the latch 234 is full. The Video 
CPU 114 can then poll the read status 232 and, if it is so 
set, read the value 233 by pulsing 235, which will reset 
the read status 232. The Video CPU 114 checks the 
write status 240 to see if the latch 245 is empty. If it is 
empty, then the Video CPU 114 presents a value 246 
and toggles the write line 244. This will set the bit latch 55 
243 and the status 240 will indicate that the latch 245 is 
full. The Control CPU 106 can then poll the read status . 
240 and, if it is set, read the value 242 by pulsing 241, 
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which will reset the read status 240. The status signals 
232 and 240 are both referenced as read and write sta- 
tus and their function depends on which CPU is polling 
the status signal. 

[0087] As shown in Fig. 4A, the Video CPU 114 pro- 
grams the video circuits 110,112,113 after which video 
signals, including video raster signals, coming from the 
Host PC VDAC (discussed in more detail in Fig. 4G) are 
processed by the Video Signal Input Circuitry 110 and 
the Video CPU 111. The resulting video data is written 
to the Video Output Buffer 1 1 5. In the preferred embod- 
iment, this buffer is 32K by 16 bits, which is enough 
memory to hold one screen of 800 by 600 digitized 
graphics or more than one screen of text data. The Vid- 
eo Processor 111 writes to this Video Output Buffer 11 5, 
so that the data written to the buffer can be read by the 
Video CPU 114. 

[0088] The video input enters from the Host PC's 
VDAC, through a video interface cable which is present- 
ly either a DB 9 pin receptacle (with TTL video signals) 
or a DB 15 pin receptacle (with analog video signals) 
located on the rear panel of the Host Unit (see Figure 3 
at references 65 or 67). For both of these receptacles, 
the horizontal and vertical syncs are TTL signals. When 
these video signals enter the Video Signal Input Circuit- 
ry 110, the circuitry selects sync polarity, TTL or analog 
mode, and a particular color signal. This signal is passed 
to the Video Processor 111. 

[0089] Analog VGA display monitors can be either 
color or monochrome. As previously mentioned the 
eighth DIP switch in the Host Unit is presently used to 
indicate whether a monochrome (i.e. DIP switch in the 
UP position) or color (i.e. DIP switch in the DOWN po- 
sition) VGA VDM is connected to the VGA OUT 64 re- 
ceptacle of the Host Unit. 

[0090] Analog (VGA) monochrome monitors general- 
ly dispfey only the green signal. When the PC is reset, 
the VDAC will interrogate the three monitor identification 
signals coming from the VDM to determine the type of 
monitor that is connected (i.e monochrome or color). If 
a monochrome monitor is detected, the VDAC will add 
together the red, green, and blue color signals and out- 
put this one combined signal to all three color gun out- 
puts. This gray scale summing is designed so that the 
same amount of brightness will be displayed in mono- 
chrome as would be displayed in color 
[0091 ] The three monitor identification signals appear 
on pins 4, 11 , and 12 of the monitor's DB15 video con- 
nector. The Host Unit currently hardwires these signals 
so as to appear to the VDAC that a color monitor is al- 
ways present (i.e. pins 4 and 11 grounded, pin 12 open), 
regardless if a monochrome or color VDM is connected 
to the VGA OUT 64 receptacle of the Host Unit. 
[0092] If a color monitor is connected to the Host Unit, 
the red, green, and blue signals simply pass through, 
and are displayed in color. When a monochrome display 
is attached, the Host Unit will apply gray scale summing 
and output this sum on the red, green, and blue signals 
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going to the display monitor. The formula for gray scale 
summing Is: 30% red + 59% green + 11 % blue. This 
gray scale summing is independent of the Host Unifs 
video processing and affects only the video output to the 
monochrome monitor. The Host Unit could determine $ 
whether or not to apply this gray scale summing by ex- 
amining the identification signals coming from the mon- 
itor, but in the current implementation, position 8 of the 
Dip Switch is used to indicate the type of VDM connect- 
ed to the Host Unit. 10 
[0093] Forcing the Host PC's VDAC to believe a color 
VDM is always connected permits the Host Unit, and 
remote users, to have access to color information, re- 
gardless of the monitor type connected to the Host PC 
via the Host Unit. In other words, this approach permits 15 
a remote user to view a Host PC's VDAC in color even 
in cases where a monochrome VDM is connected to the 
Host Unit. In addition, because Host Unit video output 
signals are buffered, the Host Unit need not have a VDM 
connected to the Host Unit. In cases where a remote 20 
user has a monochrome VDM connected to their Re- 
mote PC, the TVLINK EXE software program (dis- 
cussed later) will ignore any color attributes sent by the 
Host Unit for display purposes. 

[0094] An overview of the color signal selection cir- 25 
cuitry of the Video Signal Input Circuitry 110 is found in 
Fig. 4G. Video Select Latch 257 controls which color sig- 
nal is selected. This latch is set by the Video CPU 114. 
Latch signals-256 control the multiplexer in the Video 
Signal Select 264 which selects one of the TTL signals 30 
red 260, green 261, blue 262, or intensity 263, or the 
converted analog signal 254 and presents this signal at 
265 which will be clocked into the bit latch 267 for each 
pixel clock 266 and appear at the Bit Latch output 268. 
The VGA Color Select 255 signal causes the Analog to 35 
TTL Circuitry 253 to select a particular analog signal (i. 
e. red 250, green 251, or blue) 252, to be converted to 
a TTL output 254. 

[0095] The most preferred embodiment of the inven- 
tion presently provides for only one color signal to be 40 
processed per video raster scan cycle. Therefore, mul- 
tiple scan cycles are required to derive color text infor- 
mation. Since approximately 60 scan cycles occur per 
second, color signals can be processed and decoded to 
achieve reasonable throughput of color text data to a 45 
Remote PC. Future embodiments could add circuitry 
and/or software to allow simultaneous processing of all 
color signals by, for example, pre-digitizing each color 
signal (using shift registers and latches, as described in 
Fig. 4K) and storing this data into a separate memory so 
storage area before passing this information to the Vid- 
eo Processor 111 circuitry. This alternative approach 
would permit text and graphics color attributes to be 
more precise by avoiding potential discrepancies 
caused by processing multiple scan cycles where VDAC ss 
screen data changes between each cycle. 
[0096] As shown in Fig. 4H, analog color signals vary 
from zero volts 272 for black 278 to approximately 0.7 



volts 270 (into a 75 ohm load) for white 275. Light gray 
276 and dark gray 277 are between these two limits. To 
be processed by the present video circuitry, this analog 
signal needs to be converted to a digital TTL signal. To 
accomplish this, a threshold level is set 271 so that color 
levels above this level 274, 275, 276 are converted to a 
LOGICAL 1 (high) signal 281. Color levels below the 
threshold such as 273, 277, 278, etc. will be converted 
to a LOGICAL 0 (low). The resulting VGA Video output 
signal 280 is depicted beginning at reference point 280 
and is the output of the circuit as shown at reference 
point 297. Using this present approach, a foreground 
color of dark gray 277 on a background color of black 
278 will not be discerned by the circuitry. Neither will a 
combinations of white 275 and light gray 276. Also, al- 
though white, gray, and black 275, 276, 277, 278 are 
referenced, the actual color depends on the color signal 
selected and will be either red, green, or blue. The an- 
alog color signals 290, 291, 292 are selected by an An- 
alog Signal Select multiplexer 293 and presented to the 
positive input 294 of a comparator 296. The minus input 
295 is fixed at a threshold value 271 . The output of the 
circuit 297 is a TTL signal as illustrated beginning at ref- 
erence point 280. The circuit could use, for example, an 
Analog Devices part AD9696 comparator. 
[0097] The Video Processor handles both digitizing 
graphics and text mode character recognition. For 
processing purpose a "pixel" is equivalent to a "logical 
bit". 

[0098] As shown in Fig. 41 block 300 depicts a VDM 
displaying six characters: "A", "B", "C", "D" and two char- 
acters from the extended ASCII character set, namely 
a solid block and a cross. As shown on Fig. 4J, the total 
video signal is composed of several parts: Vertical sync 
340, horizontal sync 343, and color signal(s) 350 (illus- 
trated as only one signal). Whereas color VDAC uses 
red, gre^g, and blue signals, monochrome VDAC often 
use green and intensity signals only. As shown in Fig. 
4I, the visible portion of the VDM 302, where text and 
graphics appear, is only a subset of the total video sig- 
nal. Block 310 shows a close-up view of the upper, top 
left corner of the entire VDM 301 which includes part of 
the left, top corner of the visible VDM 302. 
[0099] As shown in Fig. 4J, the vertical sync signal 
340 commands the monitor to go to the top of the screen 
301 , 313 and start scanning downward to the bottom of 
the screen 304. The horizontal sync signal 343 com- 
mands the monitor to go to the left side of the screen 
305, 325 and scan to the right side of the screen 303. 
The color signals create visible light on the VDM's 
screen in the form of text and/or graphics 302. Although 
314 depicts the first visible horizontal scan line, there 
are horizontal scan lines above (see 301 , 313, and 352) 
the first visible scan line 314. As shown in Fig. 4J, ref- 
erence 345 illustrates the first visible horizontal scan line 
and reference 348 illustrates the last visible horizontal 
scan line. References 330 and 333 expands a single 
horizontal scan line 346. Although the first scan line 314 
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and the last scan line 31 5 for a character row represents 
16 horizontal scan lines (typical for VGA text mode), 
some older monochrome VDAC only generate 8 hori- 
zontal scan lines as shown at reference 353 between 
references 345 and 346. Reference 334 shows the first 
character row's horizontal scan line 316 over the "C" 
character on Fig. 41. Similarly, reference 336 represents 
scan line 316 over the "D". Reference 338 is the same 
scan line over the 80th character (not shown on Fig 41). 
Reference 347 represents the next horizontal scan line 
at 31 7. The horizontal sync pulse 330 starts the horizon- 
tal scan line 316. There is a delay 335, 325, 305 before 
the first visible horizontal pixel 324. 
[0100] References 324, 322, 321, and 320 position 
the first pixel of each character of a given row. The 9th 
position 323 which is presetfor VGA, Hercules, and oth- 
er VDAC (not for early monochrome VDAC which is 8 
by 8) is not taken into account. The pixel clock signal 
only captures the first 8 pixels of the character so that 
the digitized video ignores this pixel 323. 
[0101] The first horizontal scan line (non-visible) 344 
is depicted at reference 312 on Fig 41. The last visible 
scan line 348 completes a VDM's screen. Presently, 
VGA text mode has 350 visible horizontal scan lines, 
VGA graphics mode (640 x 480) has 480 scan lines, hi- 
res mode (800 by 600) has 600 scan lines, but the 
present system is capable of operating with any number 
of differing graphics modes and display lines. 
[01 02] After the horizontal sync pulse 330, and the left 
margin delay 305, 325, 335, the visible video occurs as 
illustrated at reference 337. A scan line for the first two 
characters is shown in Fig 4K beginning at reference 
360. The preferred embodiment of the Video Processor 
uses a 16 bit shift register and a 16 bit latch. Fig. 4K, 
however, only depicts an 8 bit latch and shift register for 
illustration purposes. 

[0103] As an example of the process of digitizing vid- 
eo characters, assume each character is 8 pixels wide, 
as illustrated beginning at reference 365 and ending at 
reference 370. When digitized, these eight pixel values 
make up the eight bits of a byte used for further process- 
ing. After the 8th pixel 370, there is a 9th unused pixel 
labeled "X" (shown at reference 375). This 9th pixel oc- 
curs for VGA VDAC as well as some monochrome 
VDAC. Some VDAC do not have this pixel so that the 
last pixel of one character 370 is immediately followed 
by the first pixel of the next character 373. 
[0104] Reference 361 shows an actual wave form 
from a horizontal scan line illustrated on the graph 390, 
as the last horizontal row at the base of the characters 
"L" and 11 M" ending with the pixel referenced at 394. Ref- 
erence 364 shows the bottom line of the "L", reference 
371 shows the left leg of the "M", and reference 374 
shows the right leg of the "M". 

[0105] The video pixel data 365 input 391 to the shift 
register 393 will appear at the first shift register output 
bit 395 after a clock pulse at 392. After 7 more clock 
pulses, the video pixel data 365 appears at the last shift 



register output bit 399. Thus, to digitize a character, 
each pixel data bit (e.g. 365) is shifted into a shift register, 
393 from Video signal input 391 via a Pixel Clock 362, 
392. After the 8th pixel 370 is shifted into the shift reg- 
5 ister, the data is transferred into the Latch 398 via the 
Latch Clock 363, 372 at 396. After the data is latched, 
the output of the Latch 398 indicated at reference 397 
is then stored into the Video Output Buffer 115 (Fig. 4A) 
for later retrieval by the Video CPU 114 (see Fig. 4A). 

10 For VDACs where the last pixel of one character 370 is 
followed immediately by the first pixel of the next char- 
acter 373, then Latch Clock 372 occurs coincident with 
the first pixel of the next character. 
[01 06] Once in the Video Output Buffer 1 1 5 (Fig. 4A), 

is the digitized video data can be transferred, through the 
Control CPU 106 (Fig. 4A) and out the Remote Data 
Circuitry 103 (Fig. 4A) to a Remote PC 2 (Fig. 1), which 
can then be directly displayed in graphics mode. Al- 
though presently supported, this transfer requires six- 

20 teen bytes per character which slows down the transfer 
of screen data to a Remote PC. In cases where a Host 
PC VDAC is in a text mode, screen transmission times 
can be cut dramatically by converting a character's 16 
byte packet into a one byte character code, such as 

25 used by the ASCI I coding scheme, and transmitting only 
the one byte code instead. Depending on the particular 
VDAC, characters can use 8, 9, 14, or 16 horizontal scan 
lines or byte packets, all of which are handled by the 
Host Units circuitry. For illustration purposes, 16 hori- 

30 zontal scan lines (presently used by VGA VDAC) has 
been selected for further discussion. 
[0107] The conversion from pixel data to characters 
requires some kind of character recognition of which 
several approaches are possible. The first approach is 

35 to take the digitized video and search a look-up table for 
a match of this character's 1 6 byte packet, which repre- 
sents4he reorganized pixel data which corresponds to 
a single character. The relative position in this table 
would then yield the character code, such as used by 

40 the ASCII coding scheme, associated with the desired 
character. This method is less preferred because the 
particular shapes of characters vary among different 
VDACs and the look up table would require excessive 
storage of character set mappings. Furthermore, the ta- 

45 ble would have to be updated to handle new character 
sets or character format changes. 
[0108] A second approach would be to process the 
digitized video data by certain algorithms which directly 
infer (or recognize) the character's identity such as 

50 those typically used by OCR (optical character recogni- 
tion) software familiar to persons in the trade. This ap- 
proach is less preferred because it is computation inten- 
sive requiring too much processing on the part of the 
Video CPU 114 (Fig. 4A), which slows video screen ac- 

55 cess by a Remote PC and degrades throughput to a Re- 
mote PC. 

[0109] A third approach, which is employed in the 
most preferred embodiment of the invention, uses CRC 
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methods forcharacterrecognition. Underthis approach, 
the digitized video is converted directly to CRC vafues 
by hardware circuitry, after which these values are writ- 
ten to the video output buffer. 

[0110] To convert a 1 6 byte packet to a unique CRC 
value, the packet data is serialized (dropping the ninth 
pixel, if present) and the resulting bit stream is input to 
the CRC generator. Fig 4L illustrates this process. Each 
horizontal scan line for a particular character 410, 411, 
and so forth down to 417, is processed sequentially as 
shown beginning at reference 400. -It can be seen that 
the tip of the "A" (see 412) is followed immediately by 
the top line of the "B" as shown within block 407. In the 
most preferred embodiment, the CRC generator is more 
correctly called a CRC processor, in that intermediate 
CRC values generated can be saved and then later re- 
stored to process the next horizontal scan line. First the 
CRC shift register value is set to zero. Then the first line 
of the cell containing the "A" 41 0,401 isprocessed, after 
which the intermediate CRC value is saved. Then the 
CRC shift register value is again cleared and the first 
line of the cell containing the "B" (see 407) isprocessed, 
and so on. After the entire horizontal scan line 410 is 
processed, scan line 411 begins. First, the previously 
saved intermediate CRC value forthe cell containing the 
"A" is loaded into the CRC shift register. Then, 402 is 
processed after which again the intermediate CRC val- 
ue is saved, and so on. Thus, when processing 80 col- 
umn text data, there will be 80 intermediate CRC values 
saved for each scan line. This allows the CRC generator 
to "see" 16 contiguous bytes for each character. After 
the last horizontal line 417 forthe "A" is processed, the 
resulting CRC value is the CRC for the character and is 
stored into the Video Output Buffer 1 1 5 (Fig. 4A) and so 
on for the remaining characters. Later the Video CPU 

114 (Fig. 4A) reads these CRC values and searches a 
look-up table, of character CRC values for a match. A 
special initial training process, discussed in more detail 
below, generates this table of CRC values, which reflect 
the actual VDAC characteristics of the Host PC. This 
process translates the actual character formats used by 
a given VDAC to a unique CRC for each different char- 
acter. 

[0111] Another approach to convert pixel information 
to character format would be to store all 16 horizontal 
lines of digitized data (1 6 by 80 bytes) and then process 
each character in serial order 400. Two banks of 16 by 
80 byte memory would be required so that new digitized 
data could be stored while previously stored data is be- 
ing converted to CRC values. This approach uses soft- 
ware instead of hardware to do the processing, but oth- 
erwise is suitable for use in the present invention. 
[0112] The Host Unit's circuits could be enhanced to 
include a memory translation circuit between the Video 
Processor 111 (Fig. 4A) and the Video Output Buffer 

115 (Fig, 4A) where the CRC value output from 111 (Fig. 
4A) would form the address which accessed a memory 
byte containing the character code, such as used by the 



ASCII coding scheme, for the character and store this 
code into the Video Output Buffer 115 (Fig. 4A)). The 
Video CPU 1 14 (Fig. 4A) would then read the character 
codes from the video output buffer. 
5 [0113] Fig. 4M gives an overview of the current imple- 
mentation of the Video Processor 111 (Fig. 4A)). The 
CRC generator is composed of a 16 Bit Shift Register 
439 (rather than 8 bits as shown in Fig. 4D) and a 9 bit 
Parity Generator 423 (rather than EXCLUSIVE OR 
10 gates as shown in Fig . 4D). The output of the Parity Gen- 
erator 421 is input to the Shift Register 439. The partic- 
ular output bits of the Shift Register 439 which are 
summed with the Video Input 420 is controlled by a 
Feedback Select circuit 425 (8 dual input AND gates). 

*s The first 7 least significant bits along with the most sig- 
nificant bit of the shift register output 426 is logically AN- 
Ded with 8 "enable" bits 428 from a CRC Config Latch 
429. This latch is set by the Video CPU 114 (Fig. 4A) 
and configures which of these 8 shift register output bits 

20 426 are input to the parity generator. This Latch 429 is 
used to configure the CRC generator to produce unique 
CRC values forthe video character set to be recognized. 
If this value 428 is set to zero, then all 8 bits in 424 will 
also be zero and the parity output 421 will directly reflect 

25 the Video Input signal 420. It is by this means that the 
Video Input 420 is digitized, with the latched data 442 
being stored directly into the Video Buffer 444, without 
being changed by the CRC generator. 
[01 14] The Pixel Clock 422 clocks video pixel data in- 

30 to the CRC shift register 439. As shown in block 454, 
the first pixel of the second character 453 directly follows 
the last pixel of the first character 452. The 9th unused 
bit (referred to earlier) does not appear on the graph on 
Fig. 4M as it does not have an associated pixel clock. 

35 [0115] The Temporary CRC buffer 438 is cleared by 
Clear line 433 being pulsed by the vertical sync signal. 
The ShiftiBegister 439 is cleared to zero via 431 . Then, 
8 Pixel Clocks 422 occur coinciding with the 8 pixels 
starting with 451. After the 8th pixel 452 is processed, 

40 the intermediate CRC value now appearing at the Latch 
input 427 is latched via the Latch clock 440. The shift 
register 439 is again cleared via 431 and the next char- 
acter is processed starting with pixel 453. While this next 
character is being processed, the value previously 

45 latched 441, 442 is written to a temporary CRC buffer 
438 by pulsing the write line 443. This continues until all 
characters are processed for this horizontal scan line 
and the Temporary CRC Buffer 438 contains 80 inter- 
mediate CRC values. Then, the next horizontal scan line 

50 begins. Before pixel 450 is processed, the previously 
saved intermediate CRC value in the Temporary CRC. 
Buffer 438 is loaded into the Shift Register 439 via the 
read line 437, 432, and 430. After the 8th pixel is proc- 
essed, the new intermediate CRC value is again latched 

55 441 and stored into the Temporary CRC Buffer 438, as 
described above. 

[0116] This process continues until a horizontal scan 
line 455 begins. Forthis scan, intermediate CRC values 
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are restored as before, but after pixel 456 occurs, the 
latched CRC value at 442 is the final CRC value identi- 
fying the character processed ("A" in the example) and 
is stored into the video buffer 444 via the write line 445. 
This is true for the remaining characters on this scan 5 
line 455. The next scan line begins the next row of char- 
acters and the process starting at 451 repeats until all 
25 (for an 80 by 25 video text mode) rows of characters 
are converted and all 2000 character CRC values are 
stored into the Video (output) Buffer 444, which is the io 
same as the Video Output Buffer 115 in Fig. 4A. 
[0117] A possible alternative to storing CRC values in 
the Video Buffer 444 would be to convert the CRC val- 
ues before storage into the Video Buffer 444. This could 
be accomplished by inserting a memory circuit before is 
the video.buffer, which would function as a look up table 
whereby the 16 bit CRC value referenced at 442 will 
form the memory address. The resulting 1 6 bit output of 
this memory would contain the character relating to a 
given CRC. The Video CPU would initialize this memory 20 
with CRC information. For invalid CRCs the 1 6 bit value 
is s'etto zeros. For normal character CRCs the low byte 
is set to the ASCII code of the character and the high 
byte would be set to zero. For highlighted.(inverse) char- 
acter CRCs the high byte would be set to the ASCII code 25 
and the low byte would be set to zero. This approach 
would permit immediate translation of CRCs to charac- 
ters and would improve Host Unit performance. 
[0118] As shown in Fig. 4N, the video pixel duration 
as generated by monographic VDACs is about 65 na- 30 
noseconds, and for VGA VDACs it is about 30 nanosec- 
onds. The Video time line 458 shows three video pixels: 
a white, a black, and another white pixel. VGA video re- 
quires afast Pixel Clock 459. The slanted lines indicated 
by 461 shows jitter produced when any two asynchro- 35 
nous signals interact (the video signal and the Host 
Unit's video clock). Using 90 megahertz as the base 
clock rate for pixel clock generation (in the current im- 
plementation) this jitter is about 11 nanoseconds in du- 
ration. Thus, because of this jitter, to position the rising 40 
edge of the pixel clock near the end of the video pixel 
as shown at reference 460, a resolution of 5 nanosec- 
onds was incorporated into the design. Thus, if refer- 
ence 467 shows the pixel clock at 460, the circuitry can 
reposition the pixel clock at 468, or 5 nanoseconds later, 45 
if needed. This would make the base clock appearto be 
between 180 to 200 megahertz. Of course, since the 
base clock in the current implementation is 90 mega- 
hertz, or a period of 11 nanoseconds, and the delay is 
5 nanoseconds, the position of the pixel clock follows 50 
the pattern 0ns, 5 nanoseconds, 1 1 ns, 1 6ns, 22ns, etc. 
That is, it is centered around a 190 megahertz resolu- 
tion, and it is a practical solution to achieve the desired 
result (i.e. to clock in a stable pixel data bit). 
[01 1 9] To explain jitter, the rising edge of the Horizon- 55 
tal Sync 462 pulse synchronizes .the pixel clock. Jitter is 
inherent in that it cannot be known in advance what the 
phase of the base clock will be at this time. In fact, the 



phase of this clock will be continuously changing in re- 
spectto each new horizontal scan. To illustrate this, 463 
and 464 show the base clock in different phases. Note 
that the rising edges of the base clock 465 and 466 oc- 
curs at different times after the rising edge of the sync 
pulse 462. Since the Pixel Clock 460 is derived from this 
sync signal and the base clock, the video pixels 458 in- 
herit the jitter as shown at 461 . The start and end of each 
pixel will fluctuate within the area shown at reference 
461. 

[0120] The current implementation of the Pixel Timing 
Circuit 112 (Fig. 4A) is shown in Fig. 40. Presently, this 
circuit is a 4K by 8 bit 20 nanosecond RAM memory. 
The Video CPU 114 (Fig. 4A) programs this memory via 
the data in 470, and the write line 477. This memory is 
addressed by the output 483 of a 12 bit counter 484. 
First, this counter 484 is cleared via reference 485 and, 
after each write pulse, increments the address counter 
via reference 486 (this connection is not shown on the 
figure). When processing video, the read line 478 is en- 
abled. The horizontal sync signal clears the address 
counter via the clear line 485. The output byte of the 
RAM memory 471 is split into two 4 bit nibbles 472 and 
479 and are loaded into two 4 Bit Shift Registers 473A 
and 480. A 90 megahertz Oscillator 489 clocks these 
shift registers and, via the clock signal 488 and the Di- 
vide By 4 circuit 487, loads the two nibbles into the shift 
registers every fourth clock cycle and then increments 
the 1 2 Bit address Counter 484. The two shift registers 
then output each 4 bit nibble one bit at a time at refer- 
ences 473B and 481 to generate the Pixel Clock signal 
476. The output of the Shift Register 481 is delayed 5 
nanoseconds via a 5ns Delay 482 (presently a DALLAS 
DS1 000-25) and the two signals 473B and 474 are log- 
ically ORed via reference 475 to produce the Pixel Clock 
476. Thus, the pixel clock generated can be aligned to 
the 90 megahertz clock rate every 11 nanoseconds or 
delayed 5 nanoseconds. Only one bit of one nibble at a 
time can become the pixel clock. Other means which 
could be employed include using a phase lock loop 
(PLL) or other precision delay elements to generate the 
pixel clock. 

[0121] The polarity of the vertical and horizontal sync 
signals change, as well as their relationship to each oth- 
er, depending on the VDAC in use and the particular vid- 
eo mode (e.g. text or graphics modes). As shown in Fig. 
4P., references 490 and 491 show example Vertical 
Synchronization (Sync) 490 and Horizontal Synchroni- 
zation (Sync) 491 signals. But, depending on the video 
mode or VDAC, the Horizontal Sync 491 may appear as 
shown at reference 492 and the Vertical Sync signal 490 
may appear as shown at reference 501 . To accommo- 
date this, two exclusive OR gates referenced as 498 and 
500 are used so that the sync signals which drive the 
video circuitry are always negative polarity at references 
497 and 499. The Video CPU 114 (Fig. 4A) sets the po- 
larity bits referenced at 494 and 496 to accomplish neg- 
ative polarity. 
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[0122] The phase relationship of the vertical and hor- 
izontal sync signals also vary per VDAC as shown at 
references 501 and 503. Both rising edges occur at the 
same.time. Referring to references 503 and 504, notice 
that the rising edge of 504 occurs after the rising edge 
of 503 as compared with the phase relationships shown 
at references 501 and 502. To normalize this to a con- 
sistent phase relationship, a flip-flop is used as shown 
at block 508. The VSYNC Temp signal 499 is used to 
clear the flip-flop as shown at reference 510 and the ris- 
ing edge of the HSYNC Out signal 497 which is connect- 
ed to the clock input 507 and sets the output 509 to a 
one (logical high) via data input 506 (hard-wired to +5 
volts). The VSYNC Out signal is shown as reference 
505. 

[0123] The Horizontal Control Circuitry 113 (Fig. 4A) 
implements the narrative and timing diagram for Fig. 4J 
and Fig. 4M. Referring to Fig. 4J, after the vertical sync 
begins a new screen at references 340 and 351, this 
circuitry skips the non-visible horizontal sync signals ref- 
erenced at 352, then repeats the cycle of initializing the 
CRC shift register 439 value to zero 431 , for each char- 
acter of the first horizonal scan line, saving and restoring 
intermediate CRC values via 438 forthe middle charac- 
ter scan lines, and writing the final CRC values for each 
character row to the Video output Buffer 444 (115 Fig. 
4A). 

[01 24] The Host Unit contains two microprocessors (i. 
e. CPUs) 106, 114 each with their own independent soft- 
ware operating system. Figures 5A through 5K provide 
an overview of these software operating systems. 
Source program code for the Video CPU 114 is written 
in 8032 assembly language. Source program code for 
the Control CPU 106 is also written in 8032 assembly 
language. As known to persons familiarto the trade, op- 
erating system software, such as that used forthe Con- 
trol and Video CPUs, is primarily event or interrupt driv- 
en and does not follow the linear logic flow typical of 
most application software. 

[0125] The present embodiment includes two CPUs 
primarily to spread the processing workload so as to 
give a remote user the impression (to the extent possi- 
ble) that they are actually sitting at the Host Unit. De- 
coding the high speed video signal of the Host Units 
VDAC presently requires almost all of the processing 
speed of a typical high speed microprocessor. Adding 
additional processing requirements to the CPU respon- 
sible for decoding video signals may prevent the CPU 
from neaping up with the data output of a VDAC. Hence, 
a second CPU was added to the present design of the 
Host _,nit. As noted above, however, with faster micro- 
processor technology, a single CPU could be used. 
[0126] Fig. 5A represents an overview of the Control 
CPU 106 (Fig. 4A) operating software. When power is 
first applied to the Host Unit, the CPU begins executing 
the initialization routine 600. This routine does the nom- 
inal housekeeping such as setting certain variables to 
default values, clearing counters, setting up interrupt pa- 



rameters. After this, the dip switches are accessed to 
determine the Host Units identification number. Then, 
non-volatile ram is accessed 108 (Fig. 4A) for the Host 
Unit's access password, default modem data and to 
5 check if the Host Unit is setup to process video (via train- 
ing discussed below in connection with Fig. 6). 
[01 27] If the Host Unit is ready to process video data, 
a video-ready command is sent to the Video CPU (via 
107 Fig. 4A) to indicate that video processing can com- 

10 mence. The initialize routine 600 then sets up the Re- 
mote Data Circuitry's serial data port 103 (Fig. 4A). If 
the Host Units identification number is zero, the Host 
Units data port is disconnected from the chaining port, 
the CPU's serial port transmit and receive signals are 

is directly connected to the host data port, and a modem 
which is expected to be connected to the remote data 
port, is initialized. In a case where a Remote PC is di- 
rectly connected to a Host Site via a Direct Line Linkage, 
no Host Unit with an identification number of zero would 

20 exist at the Host Site. In this instance, the Remote PC 
would presently be connected directly to the "Data In" 
receptacle of the first Host Unit on the Daisy chain. In 
this case, the first and all other Host Units present on 
the daisy-chain listen for an access request. 

25 [0128] After this initialization process is complete, the 
Control CPU waits to Process Access Requests 601 
from the Remote PC to the Host Unit. During this time, 
the "Action" button on the front of the Host Unit is also 
monitored. Should the "Action" button be pressed, then 

30 normally a "Setup" command is sent to the Video CPU 
and a "Setup" flag is set, the setup indicator on the front 
panel of the Host Unit is made to blink, and the Process 
Access Request 601 routine continues to wait. Howev- 
er, in cases where the Host Unit has been locked due 

35 to a security breach, pressing the "Action" button un- 
locks the Host Unit for remote access and resets both 
the "Sessjpn" and "Lockout" counters to zero. Finally, 
during this Process Access Request 601 wait period, 
any command received from the Video CPU will be serv- 

40 iced. Then, the Process Access Request 601 routine 
continues to wait. 

[0129] When a Remote PC first establishes a connec- 
tion with a Host Site (i.e. a carrier detect signal or a re- 
quest to send received), each Host Unit on the daisy- 

*5 chain at the Host Site reinitializes it's "Session" security 
counter to zero and session lockout flag. 
[0130] When a Remote PC issues an access request, 
each Host Unit at the Host Site checks it's identification 
number 601. If the Access Request's identification 

50 number matches the Host Units number, then the Host 
Unit responds to the access request and Password 
processing 602 begins. However, if the unit is currently 
in a SETUP mode, the Process Access Request 601 
responds BUSY and access is denied. 

55 [0131] Routine 602 now requests a password from 
the Remote PC and waits. Presently, the Host Unit uses 
a zero knowledge password protocol, whereby each 
password request contains a random encryption key 
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that encodes the password in a different manner, so as 
to make it difficult for anyone with unauthorized access 
to the data line to determine a password. 
[0132] If ho password is received after a pre-set peri- 
od of time or an invalid password is received 603, then 
a "Session" counter is incremented to count the number 
of unsuccessful access attempts during a session. If this 
counter exceeds a user specified limit, the counter is re- 
set to zero, a "Lockout" counter is incremented, a ses- 
sion lockout flag is set, and a data packet is returned to 
the Remote PC indicating that access to the Host Unit 
is denied for the session and processing returns to the 
Process Access Request routine 601. If the "Lockout" 
counter exceeds a user specif ied limit, as obtained from 
non-volatile RAM, no user will be permitted access to 
the Host Unit until the "Action" button on the front of the 
Host Unit is pressed. 

[0133] If a valid password is received 603, both the 
"Session" and "Lockout" counters are reset to zero, the 
session lockout. flag is cleared and the Process Com- 
mand routine is invoked 604. 

[0134] The Process Command 604 routine, process- 
es any commands received from the Remote PC or the 
Video CPU. The Misc. Commands subroutine 608 con- 
tains some subroutines that may be invoked by the Vid- 
eo CPU processing, after which processing will return 
to the calling routine when complete. 
[0135] The Release-Access command 605 is not a 
subroutine, but causes an end to command processing 
by returning to the Control CPU's Process Access Re- 
quest routine 601. 

[0136] The Passthru 606 and Remote Access 607 
routines are described after a general discussion of the 
Video CPU has been completed below. 
[0137] Several processes are grouped together under 
the heading Misc. Commands 608. These processes in- 
clude disconnecting the Host PC's keyboard from the 
Host PC so that the Control CPU can generate the key- 
board signal. Also included are commands which start 
a video training session remotely, or transfer video re- 
lated data (contained in non-volatile ram) to and from 
the Remote PC, change the Host Unit's password, or 
send a keyboard scan code to the Host PC (used by the 
video CPU during training). 

[0138] Fig. 5B is an overview of Video CPU's operat- 
ing software. Lines with arrows indicate processing flow, 
whereas lines without arrows indicate a called process 
or subroutine. 

[0139] When power is first applied to the Host Unit, 
the Video CPU begins executing the initialization routine 
620. This routine does nominal housekeeping such as 
setting certain variables to default values, setting up in- 
terrupt parameters, and initializing the Host Unit's data 
serial port 116 (Fig. 4A). After this, the software waits 
for a command 621 from the Control CPU 107 (Fig. 4A). 
Blocks 622, 623A, 624, 625 and the miscellaneous com- 
mand 626 are all subroutines invoked by the Wait For 
Command 621 routine, which returns processing to the 



Wait For Command routine 621 when subroutine 
processing is complete. Blocks 623A through 623E are 
parts of a single subroutine. 

[0140] If the Control CPU sends a video ready com- 
5 mand, then the Load Video Related Data 623A subrou- 
tine is invoked and waits for one second, and then re- 
quests non-volatile video related data from the Control 
CPU necessary to decode the Host PC's video output. 
After this data is loaded into the Video CPU's memory 
10 623A, the video processor hardware 110,112,113(Fig. 
4A) is initialized 623B with timing data, default sync po- 
larity, and also flags are set to indicate the video 
processing mode (monochrome or color). Then, the Ac- 
cumulate History 623E process begins to perpetually 
*s log the most recent VDAC output history to the extent 
of the Host Unit's memory. 

[01 41 ] If the video mode changed from a text mode to 
a graphics mode, history logging within the Host Unit is 
suspended until the video mode returns to a text mode. 
20 [0142] The Accumulate History process 623E initially 
captures the text data currently displayed by the Host 
PC's VDAC which is stored in a "base screen" data area 
and after this, the Accumulate History Process only ac- 
cumulates any changes which occur. If so many chang- 
es es occur that the Video CPU's memory limit is reached, 
then the oldest changes are applied to the "base screen" 
data area to free up more memory so that more recent 
changes can be stored. 

[0143] When a Host Unit is initially accessed by a re- 

30 mote user, the remote user must specify (via the TV- 
LINK.EXE program operating on the Remote PC, as dis- 
cussed below) whether or not (1) any screen history 
stored in the Host Unit's memory should be transferred 
to the Remote PC prior to beginning the access session 

35 and (2) if the user wants view only access to the Host 
site, as opposed to full access. The user's preference 
on video history and view only mode is transferred to 
the Host unit as data packets when the Host Unit is first 
accessed. If video screen history is to be transmitted, 

*o then the Accumulate History routine 623E transmits 
VDAC history data to the Remote PC by the Video CPU 
through the Control CPU's Misc. Command Routine 608 
in the form of data packets and processing returns to 
the Wait For Command 621 routine. Otherwise, the 

45 processing returns to the Wait For Command 621 rou- 
tine. 

[01 44] If the remote user has requested full access to 
a Host Site's Host Units, as opposed to view only ac- 
cess, the Remote PC sends a Remote Keyboard com- 

50 mand to the Host Unit which invokes the Misc. Com- 
mands subroutine 608 that causes the Host PC's key- 
board signals to be generated by the Host Unit instead 
of the Host PC's keyboard. Then, the Remote PC sends 
a Remote Access command to invoke the Remote Ac- 

55 cess 607 subroutine. 

[0145] First, the Control CPU Remote Access 607 
subroutine instructs the Video CPU to begin it's Remote 
Access 622 subroutine processing. The Remote Access 
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subroutine 622 causes video text to be captured and 
sent via the Control CPU to the Remote PC for display. 
The last status of the screen data sent is compared to 
the contents of the current screen and only changes in 
the VDM data are sent. 

[0146] Fig. 5C shows an overview of the data flows 
between the TVLINK.EXE software executing on the 
Remote PC 630A, the Host Unit 630B, and the Host PC 
630C. Remote keyboard 631 A and mouse 631 B activity 
are handled byTVLINK.EXE interrupt processes which 
combine and transmits this data 633, 634 to the Host 
Unit 632. The Control CPU 636A separates this data, 
sending mouse information to the Video CPU 636B 
which forwards it as serial input 638 to the Host PC. The 
keyboard data transmitted is converted to keyboard 
clock and data signals 637 which pass into the Host PC's 
keyboard input receptacle. Host PC Video signals 639 
from the VDAC are converted to coded text data, such 
as ASCII coded text data, by the Video CPU and trans- 
mitted through the Control CPU to the Remote PC 635 
where it is processed by TVLINK.EXE for output to the 
Remote PC's VDAC. Note that the transmit and receive 
data lines shown at 632 may be connected directly or 
connected via modems or other communication devic- 
es. 

[0147] To accomplish file transfers between the Re- 
mote PC and the Host PC, first a file-transfer program 
called TVFILES.EXE (provided with the apparatus and 
installed on the Host PC's mass storage device) is in- 
voked on the Host PC by typing in the program name 
from the Remote PC keyboard using the Remote Ac- 
cess process 607. Then the file transfer function is se- 
lected from the TVLINK.EXE menu of the Remote PC. 
TVLINK.EXE will then send a packet containing a Pass- 
thru command to the Host Unit. The Control CPU re- 
ceives this command 604 and Passthru mode 606 sub- 
routine is invoked. 

[0148] The Passthru Mode 606 subroutine first sends 
a Passthru command to the Video CPU's Wait For Com- 
mand 621 routine which causes the Passthru 624 sub- 
routine in the Video CPU to be invoked. The Control and 
Video Passthru 606, 624 subroutines work together so 
that data received from the Remote PC is forwarded via 
the Video CPU to the Host PC's serial port. Data re- 
ceived from the Host PC is forwarded via the Control 
CPU to the Remote PC. Thus, TVLINK.EXE (running on 
the Remote PC) communicates directly with the file- 
transfer program (running on the Host PC) and It is the 
responsibility of these two programs to produce the file 
transfer either from the Host PC to the Remote PC or 
vice-versa. 

[0149] Video Training and Setup 625 is invoked when 
the Setup command is received from the Control CPU, 
after the Action button is pressed on the front panel of 
the Host Unit. This process interfaces with^a software 
program running on the Host PC called TVTRAIN.EXE, 
which is provided with the apparatus and accessible 
from the Host Unifs mass storage device, as discussed 



in the narrative supporting Fig. 6A to 6D. To send data 
to the program, the Video Training and Setup subroutine 
625 commands the Control CPU to send "keystrokes" 
to the program, and receives data from the program by 

s processing the VDAC's video signals including a video 
raster signal. This process is described in more detail in 
connection with Figures 6A, 6B, and 6C. 
[0150] During Remote Access 622 and Video Training 
and Setup 625, certain subroutines are used to capture 

10 and interpret video data. Video graphics is captured and 
digitized by the Capture Video 640 graphics subroutine. 
This subroutine first checks that the horizontal sync and 
the vertical sync did not change in polarity, and then 
waits for the vertical sync to become active, at which 

15 time it enables the video processing circuitry and waits 
for the next vertical sync. At this point, the video. output 
buffer contains the digitized video data. This data is then 
transmitted to the Remote PC where TVLINK.EXE pro- 
gram can display this data in graphics mode. This data 

20 is also used by the training process (described below) 
to adjust pixel clock timing. The video circuitry must be 
properly initialized (see 110, 111, 11 2, 113 Fig. 4A) with- 
out CRC. 

[01 51 ] If the polarity of the sync signals change 641 , 
25 this routine aborts and returns 642 the Video Status. 
Otherwise the Capture Video 640 graphics subroutine 
returns OK 643. 

[0152] To capture video text, the video circuitry must 
be properly Initialized (see 110, 111, 112, 113 Fig. 4A) 

30 for text mode with CRC. Then, the Capture Video 644 
text subroutine captures video text and 2000 CRC's (for 
a 80 character by 25 line text mode). Presently, both the 
Graphics and Text Capture Video subroutines 640, 644 
are the same subroutine. This results because the video 

35 processing circuitry is initialized differently that charac- 
ter CRC's, rather than digitized video, is stored into the 
video output buffer. 

[0153] If the sync polarities have changed 645, Cap- 
ture Video 644 subroutine processing ends and the vid- 

40 eo status is returned to the calling routine 646. Other- 
wise, the video circuitry loads each character CRC from 
the video output buffer and, via a look-up table, trans- 
lates these CRCs to character codes (such as one byte 
character codes used by the ASCII coding scheme) 

45 stores these codes into memory via a data-pointer wh ich 
was initialized prior to calling this subroutine 647, and 
then returns OK 648. 

[0154] Fig. 5E shows the Capture Video 644 subrou- 
tine (at 650B, 651 B, 652B) being used to capture text 

50 data from the red, green, then blue color signals. Before 
capturing text data, the particular color signal is selected 
at 650A, 651 A, 652A (discussed previously in the nar- 
rative for Fig. 4G). The Capture Video Text 650B, 651 B, 
652B subroutine will return the video status 650D, 651 D, 

55 652D if the sync polarities change 650C, 651 C, 652C. 
Otherwise, the Capture Video Text subroutine returns 
OK at 653 after capturing video text information from the 
Red, Green and Blue color signals. 
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[0155] Fig. 5F illustrates some of the data storage ar- 
eas used by video subroutines. The character data gen- 
erated from the Capture Video Text subroutine 650B, 
651 B, 652B is stored into corresponding data areas 
660A, 661 A, 662A. These subroutines also update a bit s 
flag (in 660B, 661 B, 662B) for each character. A bitflag 
indicates whether a character is normal or inverse (high- 
lighted). 

[0156] Using the red, green, and blue text data and 
bitflags, each character value, such as the ASCII value, 10 
and color attributes (foreground and background) can 
be determined. Fig. 5G shows 5 characters 665A, 665B, 
665C, 665D, 665E, each with different foreground and 
background color combinations. For each of these, 
there is also shown the characters derived from the 1B 
three color signals after each signal is used to derive the 
related CRC. The foreground and background colors 
will be each represented by a three bit number with each . 
bit corresponding to one of the three primary colors. This 
three bit quantity can take on values 0-7, where black is 20 
0 (000b), blue is 1 (001b), green is 2 (010b), light blue 
is 3 (011), red is 4 (100b), violet is 5 (101b), yellow is 6 
(110b) and white is 7 (111b). The preceding numbers in 
parenthesis are the binary equivalent of the three bit val- 
ue and will be used in the discussion. The combination 25 
of red, green, and blue light make white. In cases where 
the analysis of a color signal yields a CRC that is "nor- 
mal" video, the corresponding bit value of that signal will 
be 1 for ON and 0 for OFF. Otherwise, if the signal 
matches an inverse CRC, the bit value of the signal will 30 
be reversed (i.e. set to 0 for ON and 1 for OFF). 
[0157] The process of how the three-color primary 
color signals are used to derive the foreground and 
background colors is illustrated in Fig. 5G and Fig. 5H. 
[0158] For White (foreground) on Black (background) 35 
665A, each color signal matches a "normal" CRC for an 
"A". Accordingly, 666A shows a red "A" on a black back- 
ground, which means the red signal is ON for foreground 
(i.e. 1) and OFF for background (i.e. 0). Similarly, 667A 
shows a green "A" and 668A shows a blue "A", also on 40 
black backgrounds. Together these three color signals 
appear on a computer monitor as a white "A" on a black 
background. On this basis the bit values would yield: 
Foreground: 111b, background: 000b. 
[0159] For White on Blue 665B, the blue signal 668B 45 
is always on. It supplies the blue background color and 
it also combines with the red "B" 666B and the green 
M B" 667B to create the white foreground color of the "B". 
The CRC for the red and green signals yield a "normal" , 
B character. Hence, the first two foreground bits are "11" ' so 
and background bits are "00". The CRC for the blue sig- 
nal yields a "normal" solid blue block CRC character 
where both the foreground and background colors are 
blue (i.e. ON). Hence, both the third foreground and 
background bits would be set to 1 . On this basis the bit ss 
values would yield: Foreground: 111b, background: 
001b. 

[01 60] For Yellow on Blue 665C, the red "C" 666C and 



the green "C" 667C are ON and combine to create the 
yellow foreground color. When the red and green sig- 
nals' CRCs are analyzed, a "normal" CRC "C" character 
results, which means the first two bits are set to fore- 
ground value of 1 and a background value of 0. When 
the blue signal's CRC is analyzed, the blue signal 668C 
forms the background only and is not part of the fore- 
ground color, since the signal matches a "inverse" CRC 
forthe letter "C". On this basis the bit values would yield: 
Foreground: 110b, background: 001b. 
[0161] For Red on Blue 665D, the red "D" 666D cre- 
ates the foregrou nd color and hence matches a "normal" 
CRC for the letter "D". So, the first bit would be set to 1 
for the foreground and 0 for the background. 
The green signal 667D is off, or black; does not contrib- 
ute at all; and matches the CRC value for a "normal" 
space. So the second bits for both the foreground and 
background would be set to 0 (i.e. OFF). When the blue 
signal's CRC is analyzed, the blue signal 668D forms 
the background only and is not part of the foreground 
color, since the signal matches a "inverse" CRC forthe 
letter "D". On this basis the bit values would yield: Fore- 
ground: 100b, background: 001b. 
[01 62] For Yellow on Violet 665E, the red signal 666E 
is always on and with the green "E" 667E combine to 
create the yellow foreground color and combines with 
the blue background color 668E to form violet. Since the 
red signal is "ON" to achieve both the foreground and 
background colors, the red signal matches the "normal" 
CRC for a block character and the first bit for both the 
foreground and background would be set to 1. The 
green signal combine with the red signal to define the 
yellow foreground forthe "E" character, but is not a part 
of the background color and is hence OFF for back- 
ground purposes. On this basis, the green signal would 
match the CRC for a normal "E" character and cause 
the second bit to be set to 1 forthe foreground and 0 for 
the background. The blue signal 668E does not contrib- 
ute to the foreground but contributes to the background 
and combines with the red signal 666E to form violet. 
When the blue signal's CRC is analyzed, the blue signal 
668E forms the background only and is not part of the 
foreground color, since the signal matches a "inverse" 
CRC forthe letter "E". On this basis the bit values would 
yield: Foreground: 110b, background: 101b. 
[0163] For Yellow on Green 665F, the blue signal 
668F is off, or black, and does not contribute anything. 
Hence, the blue signal translates to ia CRC for a "normal" 
space, where the third bit would be off for both the fore- 
ground and background. The green signal 667F sup- 
plies all of the background color and also combines with 
the red signal 666F to create the yellow foreground 
color. Hence, the CRC forthe green signal yields a "nor- 
mal" block character where both the foreground and 
background for the second bit would be set to "1 ". The 
red signal only contributes to creating the foreground of 
the "F". Hence, the red signal would yield the "normal" 
"F" character which would set the first bit to a foreground 
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of "1" and a background of "0". On this basis the bit val- 
ues would yield: Foreground: 110b, background: 010b. 
[01 64] For Black (foreground) on White (background) 
665G, each color signal is identical and yields the CRC 
for an "inverse" "G" character. 666G shows a black "G" 
on a red background. Similarly 667G shows a black "G" 
on a green background and 668G shows a black "G" on 
blue background. Togetherthese three color signals ap- 
pear on a computer monitor as a Black "G" on a white 
background. On this basis the bit values would yield: 
foreground: 000b, background: 111b. 
[0165] Other characters follow a similar pattern, ex- 
cept forthose characters which result in a solid block or 
a space. 

[0166] When an analysis of all three color signals 
yields a character that is a solid block 665X, 665Y, 665Z, 
the character ASCII code is always stored as a hex DB 
block with both the foreground and background at- 
tributes set to the color of the block. This approach im- 
proves processing efficiency as discussed below. 
[0167] A Black block is shown at 665X. All the color 
signals 666X, 667X, 668X, are off, or black. The CRC 
f or each color character 666X, 667X, 668X will be trans- 
lated to a "normal" space character (ASCII hex 20) but 
the character at 665X will be set to a block (ASCII hex 
DB) with foreground of 000b and a background of 000b. 
[0168] A White block is shown at 665Y. All the color 
signals 666Y, 667Y, 668Y, are on . The CRC for this char- 
acter will be translated from each color signal to a block 
(ASCII hex DB). On this basis the bit values would yield: 
foreground: 111b background 111b. 
[01 69] A Yellow block is shown at 665Z. The blue color 
signal 668Z is off, or black, and does not contribute an- 
ything and hence is translated to the "normal" CRC 
space character.. The red 666Z and the green 667Z are 
on in both the foreground and background to combine 
to make the solid Yellow Block. The CRC for this char- 
acter will be translated to an ASCII value of hex DB. On 
this basis the bit values would yield: foreground: 110b 
Background 110b. 

[0170] The ASCII hex 00 (null character) and ASCII 
hex FF characters are identical (as displayed) to a solid 
block 666X, 666 Y. Presently, these characters are trans- 
lated to a block (hex DB) character. The ASCII code 00 
is used to represent a character who's CRC is unknown 
(not in the CRC look-up table). This can occur for two 
reasons. One, when noise, or other transients corrupts 
the video signal, and two, when the presence of the Host 
PC VDAC's hardware flashing cursor periodically ob- 
scures the character. The ASCII code hex FF is defined 
as an invalid character and is used to clear (initialize) 
ASCII video data areas. 

[0171] A discussed above, a "normal" character is de- 
fined as a foreground color on black background such 
as 666F. Whereas an inverse or "highlighted", character 
is defined as black on a background color such as 666G. 
A character CRC will uniquely identify whether a partic- 
ular character is normal or inverse depending on wheth- 



er the applicable color signal is translated to a character 
using the "normal" or "inverse" character set. When ex- 
amining the red, green, and blue characters, each char- 
acter can be one of the following ASCII codes: a space 
s (hex 20) 666X, a block (hex DB) 666Y, or the ASCII code 
of a particular character 666F or 666G. So, in deriving 
the three bit foreground and background color values, 
the process is as follows: for each particular color, if the 
character is a space, which is all black, then the fore- 
10 ground bit and background bit for this color are both set 
to zero. If it is a colored block character, then the fore- 
ground bit and background bit for the color are both set 
to one. Otherwise, the character normal/inverse flag de- 
termines the setting of the color bit: normal sets the fore- 
's ground bit and inverse sets the background bit. 

[0172] To determine a character code, if all three color 
characters are either spaces or blocks (such as 665X, 
665Y, 665Z), then the character is a block 665X. Other- 
wise, the character is any non-space, non^block char- 
20 acter found (such as 665F). If there is more than one 
non-space, non-block character, they must be equal. If 
two such characters are encountered and are not equal, 
then the character is set to hex 00 (unknown character). 
Also, if any color character is unknown (unrecognized 
25 CRC), then the resulting character is also set to hex 00. 
[0173] The character comparison, to determine the 
differences, as referenced above, include both the AS- 
CII code as well as the color attributes. If foreground 
color changes from one character to the next, then this 
30 color change information is processed. If background 
color changes from one character to the next, then this 
color change information is processed. If the character 
code changes, the new character will be processed. 
Blocks (ASCII hex DB) need special attention because 
35 they may be interpreted as spaces depending on the 
foreground and background color values. For instance, 
if White oa Black text is being processed, such as 665 A, 
then the Black block 665X will be a space (hex 20) and 
the White block 665Y will be a block (hex DB). If how- 
40 ever, Black on White text is being processed 665G, then 
the space 665X will become a block since the fore- 
ground color is black. Similarly, the White block 665Y 
will become a space since the background color is 
White. This is determined by examining previously proc- 
45 essed character's color attributes. If the entire video 
screen is blank (all spaces being displayed) this may be 
interpreted as 2000 spaces with Black background or 
20C0 blocks (Blackforeground). It does not matter, since 
they are equivalent. The only reason to differentiate 
so spaces from blocks is for efficiency since only the ASCII 
code need be processed, rather than processing fore- 
ground and background information. Since typical 
screens are composed of a significant amount of blank 
space, avoiding the need to process foreground and 
55 background information improves overall performance 
of the video signal translation process. 
[0174] From the above discussion it will be clear to 
person of skill in the art that the color attributes of the 
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characters displayed on the Host PC VDM can be inter- 
preted and transmitted to a Remote PC using the 
present invention. The examples listed above are illus- 
trative of the method employed by the present invention, 
which can be used to determine the color attributes of 
any characters displayed on the Host PC VDM. 
[0175] When video text is first processed for remote 
access, the Current Screen 663A is initialized to hex DB 
(the block character) and color attributes 663 B are ini- 
tialized to zero (black foreground and background). 
These two data areas comprise the current text data 
captured and represent a blank screen. Each new cap- 
tured text screen is then compared to this current screen 
data and only the differences are processed (i.e. either 
sent to TVLINK.EXE or logged as history) and updated 
to the current screen data. Thus, by initializing the cur- 
rent screen data with hex DB and color attribute of zero, 
only the first non-blank video text data captured is guar- 
anteed to be different/and thus be completely proc- 
essed. After this, only the differences will be processed. 
The initial text data and subsequent differences will be 
transmitted to the Remote PC via the Control CPU. 
Transmitting only changes over relative slow speed tel- 
ephone lines substantially reduces the amount of time 
required to transmit Host PC video display information 
to a Remote PC. Furthermore, using data compression 
techniques familiar to persons in the trade further reduc- 
es the time needed to transfer data to a Remote PC. 
[01 76] To accumulate video text history, video text da- 
ta is first captured and stored into the current screen 
663A and the Base Screen 664A data areas as well as 
the color attribute data areas 663B, 664B. After newly 
captured text data is compared to the current screen da- 
ta, only the differences are stored by the Accumulate 
History routine 623E in the History of Changes 664C da- 
ta area and then updated to the current screen data. 
When the History of Changes data area 664C becomes 
full, the oldest changes are applied to the base screen 
664A, thus freeing more storage space 664C. 
[0177] Some Remote users may wish to sacrifice 
color attributes forfastertransmission of text data. Pres- 
ently, the remote user is given the option (via the TV- 
LINK.EXE program running on the Remote PC, dis- 
cussed later) to chose between one of the three color 
signals in lieu of color detection using all three colorsig- 
nals, as previously described. When one color signal is 
selected, the Video CPU processes only that color sig- 
nal and sends back normal and inverse video text data, 
in certain cases, characters may be formed solely by 
color signals other than one signal selected. In these 
cases, the correct character cannot be determined. For 
example, a blue character on a black background will 
not be detected on either the green or red color signals. 
[0178] The Control CPU's keyboard interface emu- 
lates the Host PC's keyboard. Keyboard signals (either 
from the keyboard or the Control CPU) pass through two 
stages before reaching the application program running 
on the Host PC. The application program could include 



the DOS COMMAND.COM program. When any key is 
pressed and/or released, the keyboard sends one or 
more serial data bytes to the Host PC. These bytes are 
processed by a dedicated micro-controller within the 
5 Host PC, which translates this information to scan 
codes, and asserts interrupt 9 to communicate to. the 
Host PC's central processors (for example a 80386 mi- 
croprocessor). This interrupt invokes a BIOS routine 
which translates the scan code to an ASCII (or extend- 
10 ed) character code and places it in a buffer for use by 
the current application. Although some application pro- 
grams may bypass the BIOS and service this interrupt 
directly, it will not affect the operation of the present in- 
vention. Examples of extended character codes include 
15 the HOME, LEFT ARROW, and INSERT keys. 

[0179] The keyboard uses a bi-directional synchro- 
nous serial protocol (8 bit plus parity) to communicate 
with the Host PC and the Control CPU emulates this in- 
terface when a Remote user is accessing a Host Unit. 
20 Fig. 5K shows the keyboard clock 671 A and data 670A 
signals. These signals are held at a logical high of 5 volts 
by a pull-up resistor. The Host PC or keyboard asserts 
a logical low (0 volts) on these lines by use of an open- 
collector driver. For each bit transmitted, data is first as- 
25 serted (high or low) (i.e. 670D) after which the clock is 
driven low for approximately 50 microseconds (i.e. 
671 C). The transfer of data is controlled by the key- 
board, not the Host PC. That is, when clocking data to 
or from the Host PC, it is the keyboard which produces 
30 the clock signal. 

[0180] When a key is pressed, the keyboard sends a 
byte or bytes to the Host CPU. It first asserts a serial 
"start" bit 670B, asserts a clock pulse 671 B, then as- 
serts the first data bit 670C, and so on, until the 8th data 
35 bit.670E and parity 670F has been clocked. Then, a stop 
bit 670G is asserted with clock pulse 671 D. This ends 
the byte transfer. At this time, when the clock pulse is 
brought high 671 E, the Host PC asserts a low on the 
clock line. This will remain low 671 F until the Host PC 
40 has finished processing this data byte, at which time, 
the clock line will go high 671 G and the keyboard can 
send another byte. For keystrokes such as, for example 
"A" through "Z", 670A and 671 A show the protocol in- 
volved, data flow is from the keyboard to the Host PC. 
45 [0181] For keys such as CAPS-LOCK, NUM-LOCK, 
and SCROLL-LOCK, data flows both ways. That is, the 
Host PC controls the state of these functions. When the 
NUM-LOCK key is pressed, for example, the keyboard 
sends this information to the Host PC after which the 
50 Host PC sends the status of all three functions which 
activate the NUM_LOCK, CAPS-LOCK, and 
SCROLL-LOCK indicators on the keyboard. The clock 
and data protocol for this is shown at 672A and 673A. 
When the NUM LOCK key is pressed, the start bit 672B 
55 and first clock 673B begins the byte transfer. After the 
byte is transferred, the keyboard brings the clock line 
high 673C which the Host PC will immediately bring low 
again 673D to indicate busy. During this busy time, the 
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Host PC brings the data line low 672C to request a data 
transfer to the keyboard. When this happens, the key- 
board waits for the Host PC to set the clock line high 
again 673E at which time the keyboard now generates 
the clock pulses 673F. Note, that the data signal at 672C s 
also serves as the start bit. With each clock signal, the 
keyboard shifts the Host PC's data 672D into its mem- 
ory. When the transfer is done, the keyboard sets the 
clock line high 673H and the Host PC brings it low again 
673G to indicate busy. When finished, the Host PC 10 
brings the clock line high 673J to indicate it is ready for 
more keyboard data. If after the Host PC has brought 
the clock line low 673G and the Host PC has more data, 
the data line is again brought low as illustrated at refer- 
ence 672C and another data transfer, from the Host PC is 
to the keyboard, will take place. 
[0182] This concludes an overview of the ciock and 
data protocol. Although one-byte transfers are de- 
scribed to explain the mechanisms for bi-directional da- 
ta transfer, when a key is pressed, released, or for "lock" 20 
key activity (NUM-LOCK, etc.) muiti-byte transfers are 
actually involved. Keys such as Print-Screen, Sys-Req, 
or CLT-Break also have their own multi-byte protocol. 
[0183] Fig. 6A illustrates the main training screen 681 
presently generated by theTVTRAIN.EXE program dis- 25 
tributed with the apparatus. 

[01 84] Processing parameters needed to decode the 
video signals for a VDAC into digital or text data may 
vary from VDAC to VDAC and may change further 
should VDAC technology change. The TVTRAIN.EXE so 
program is invoked on the Host PC. The program per- 
mits the Host unit to decode the actual video output sig- 
nals of a VDAC, including the video raster signals, 
against known data displayed on the screen to deduce 
the exact processing steps required to decode the out- 35 
put of the VDAC. This approach permits the apparatus 
to process video regardless of the VDAC technology 
employed. These processing parameters are stored in 
the form of data tables stored in the Host Unit's non- 
volatile RAM, which are referenced by software pro- *o 
grams operating in the Host Unit Video CPU that decode 
the Host Unifs video signals. Once the TVTRAIN.EXE 
process has been successfully completed for a HOST 
PC, the process need not be repeated unless the Host 
PC's VDAC or VDM is changed or a new Host PC is 45 
connected to the Host Unit. 

[0185] When the TVTRAIN.EXE is invoked on a Host 
PC, the Host PC waits for a specific series of keystrokes 
to be received from the Host Unit to begin the training 
process. Thereafter, the Host Unit controls the activities so 
oftheTVTRAIN.EXE program via keyboard input to the 
Host PC. After the TVLINK.EXE has been invoked on 
the Host PC, the "Action" button on the front of the Host . 
Unit must be pressed to instruct the Host Unit to begin 
sending keyboard data to the Host PC. Thereafter, the 55 
Host Unit continues to control the TVTRAIN.EXE via 
keyboard input until the training process is complete. 
When training is in process the "Setup Mode" indicator 



light on the front of the Host Unit blinks. 
[0186] During the training process a video screen is 
presently displayed on the Host PC VDM as shown in 
Fig 4A. This video display uses only black and gray or 
white unless otherwise noted. 

[0187] The dashed horizontal line beginning at refer- 
ence 683 shows 40 half block characters (hex DF) from 
the ASCII character set. Each of these characters alter- 
nate with a space. The next solid horizontal line begin- 
ning at reference 684 contains 80 half block characters 
(hex DF) forming a solid bar. The third vertical line be- 
ginning at reference 685 through the twenty-fourth 687 
row contain a hex B1 character in the first column (also 
shown enlarged at 680A. The twenty-fifth line (i.e. row) 
contains 80 characters (hex DC) as shown beginning at 
reference 688. 

[01 88] As the first step in the training process, the hor- 
izontal and vertical sync polarities are determined and 
then the video processing circuitry is initialized to digi- 
tize the video data (the CRC configure latch 429 is set 
to zero) by the Video CPU in the Host Unit. There are 8 
pixel clocks per character and with 80 characters per 
row, a total of 640 pixel clocks are needed. Each of these 
pixel clocks is initialized to a small default value to place 
them approximately 25 nanoseconds parts. 
[01 89] Then, to determine whether the video signal is 
analog or TTL, the green analog signal is selected and 
video is captured. The video data is then scanned for 
black and white activity which will be found when data 
relating to 683 is encountered. If the data is all zeros or 
all hex FF's, then the monitor is not analog and the TTL 
green signal will be selected, and video activity checked 
again. If video is still not detected, then the Video CPU 
instructs the Control CPU to send a keystroke to the 
Host PC, via the keyboard interface, instructing 
TVTRAIN to display an error message. Otherwise, the 
video traieing process continues. 
[0190] Next, a video screen is captured. First, the 
number of non-displayable horizontal scan lines 682 
must be determined. This is done by counting each 80 
byte (one scan line) until a non-blank scan line is found 
(i.e. reference 683). Second, starting with the first non- 
blank scan line 683, scan lines are counted, until the 
next horizontal line (i.e. reference 684) is encountered. 
This gives the number of horizontal scan lines needed 
to generate a character. 

[0191] With this information, the training process con- 
tinues to capture the video, ignoring the first two rows 
683, 684 and begins adjusting the pixel clock timings 
using the columns in the vertical line between 685 
through 687. This column 685 is shown in more detail 
at 680A. The blank space referenced at 680B shows 
the first pixel of the character hex B1 . The black square 
referenced at 680C shows the first pixel of the next scan 
line. The series of blank and black squares referenced 
by 680D shows the first character in it's entirety. In a 
VGA mode 1 6 horizontal lines are needed to make the 
character. The next character referenced at 680E im- 
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mediately follows the first character thus supplying an 
unbroken series of alternating pixels (i.e. 680B, 680C, 
and downward). The vertical column of hex B1 charac- 
ters indicated by 685 to 687 include 352 horizontal scan 
lines for VGA text mode video (16 scan lines by 22 
rows). For some monochrome adapter cards using 8 
scan lines per character row, there are only 176 scan 
lines. In any case, 100 scan lines of the column 685 to 
687 are used in the training process. 
[0192] Fig. 6B shows the first four horizontal scan 
lines of 680A and associated data streams. The pixel 
referenced at 680B is shown again at reference 690B. 
The 8 character pixels starting with 690B is shown as a 
data stream at 690F. Similarly, 690C is shown at 690G, 
690D is shown at 690H, and 690E is shown at 690J. 
Pixel clocks positioned correctly are shown on the line 
beginning at reference 690K. Correct positioning is 
when, the pixel clock will reliably capture pixel data with- 
out errors due to jitter. Pixel clock 690M captures the 
first pixel or data bit, the following 7 pixel clocks captures 
the remaining 7 pixels, producing a data byte for each 
scan line. The value of this byte for 690B, 690F is 55 
hex or 01010101 binary. The value of the next byte for 
690C, 690G is AA hex or 10101010 binary. The first pixel 
is the Most Significant Bit (MSB) of the resulting byte 
value. 

[0193] Note that as shown, the first pixel 680B of the 
character hex B1 is a zero data bit and that 680C is a 
one data bit. For some video adapter cards however, 
the hex B1 character is reversed. That is, the first pixel 
680B of the character hex B1 is a one data bit and that 
680C is a zero data bit. Since the Host Unit knows the 
expected character contents of each screen location, 
the Host Unit can automatically detect this reversal, 
which illustrates how the apparatus can automatically 
adapt itself to diverse VD ACs through this training proc- 
ess. 

[0194] A primary subroutine involved in the training 
process evaluates the correctness of a pixel clock posi- 
tion in relation to the video pixel data. This routine proc- 
esses 100 scan lines. Each scan line is digitized to 80 
bytes, each byte representing one scan line of a char- 
acter. Before calling this subroutine an INDEX and a 
MASK value is set. The INDEX selects one of the 80 
bytes across the screen. The INDEX starts at zero, 
which is the left most column, moves across the screen 
one column at a time and ends at 79, which is the right 
most screen column 689B. The MASK selects one of 
the bits within a byte referenced by this INDEX. Refer- 
ence 690R show a table of these MASK values. 
[0195] As the first step in this subroutine, the pixel at 
690B is tested. If it is zero, then a COUNTER is incre- 
mented. Then the pixel at 690C is tested. If it is non- 
zero, then a COUNTER is also incremented. This is re- 
peated for pixels 690D, 690E, and so on.-testing for al- 
ternating pixel values, until 1 00 pixels have been tallied. 
The value of the COUNTER should now equal 1 00 and, 
if so, then the pixel clock 690M is correct. If it is less than 



100, then the pixel clock needs to be repositioned, and 
the pixel column 690B rechecked. After pixel clock 
690M is positioned correctly, then pixel clock 690N is 
selected. At this point, the first pixel in this pixel column 
5 (to the right of 690B) will be a one instead of zero at 
690B. 

[0196] Initially, the INDEX for the pixel clock refer- 
enced at 690M is set to zero and the MASK is set to hex 
80. After the pixel column is processed and the COUN- 
TS TER equals 100, then the MASK is shifted right to be- 
come hex 40, to test 690N, then it is set to hex 20 for 
690O, and hex 1 0 for 690P, until the eighth pixel column 
is processed with the MASK equal to hex 01 . The eight 
pixel clocks for this column of characters (i.e. 685 to 687) 
15 are now positioned. 

[0197] The Video CPU now instructs the Control CPU 
to send a keystroke to the Host PC, via the keyboard 
interface, which instructs the TVTRAIN.EXE program to 
move the column of hex B1 characters 685,687 over to 

20 the next column at 689A. The training process now in- 
crements the INDEX by one and sets the MASK to hex 
80, and proceeds to position the next 8 pixel clocks 
690Q. This process is repeated until the last column at 
689B has been processed (INDEX equals 79). The pixel 

25 clocks now correctly capture the 640 pixels. 

[0198] When the horizontal scan line begins 690A, 
there is a blank area or left margin 686 before visible 
pixels commence. When attempting to position the first 
pixel clock at 690M, it may be at 690L or some other 

30 location. Notice here that the data streams 690F, 690G, 
690H, 690J and so on, wiil all have a value of zero. So 
when the subroutine, described above, processes this 
data, the value in COUNTER will be 50 since only half 
the pixels are of the correct value. That is, they are all 

35 zero whereas the subroutine expects alternating pixel 
values. On this basis, the training process permits the 
unit to-automatically adjust to the blank areas present 
for a given VDAC by skipping over situations where the 
vertical pixel counter is 50. 

40 [0199] Signal interference or noise may cause minor 
distortions during the training process in the pixel 
COUNTER. Therefore, a tolerance of plus or minus 3% 
is presently permitted when setting the pixel clocks. In 
addition, in cases where a pixel clock appears to be out 

45 of such expected ranges, processing for the pixel clock 
is automatically repeated up to 10 times to resolve the 
problem. If the problem cannot be resolved at that point, 
the training process is terminated and an error messag- 
es is displayed suggesting that another VDAC or Host 

50 Unit be used. 

[0200] Figure 6C shows the effect of pixel clock timing 
on the COUNTER value. Waveforms 692A and 692B 
show several pixels from two scan lines including jitter 
692M. Waveforms 692C, 692D, 692E, 692F, 692G, 

55 692H, 692J show the pixel clock pulse of 690N at dif- 
ferent timing positions. This pixel clock as shown at 
692H is correctly positioned for 690N. The pixel clock 
shown at 692C is actually positioned at the previous pix- 
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el 690M, 690B, 690C. The COUNTER value resulting 
from this clock pulse will be zero because none of the 
pixels are correct. As explained, pixel clock 690N ex- 
pects a consistent pixel value of one 692K followed by 
a pixel value of zero 692L. £ 
[0201] At 692D, the COUNTER value will be approx- 
imately 1 0 because, due to jitter, the pixels will be correct 
1 0 percent of the time. 

[0202] At 692E, the COUNTER value will be approx- 
imately 50. At 692F, the COUNTER value will be approx- . 10 
imately 90. At 692G, the COUNTER value will be close 
to 1 00 (dueto insufficient data setup time requirements). 
At 692H, the COUNTER value will be 1 00. At 692J, the 
COUNTER value will again be close to 90. 
[0203] After the pixel clock timing has been deter- *5 
mined, the Video CPU instructs the Control CPU to send 
a key stroke to Host PC, via the keyboard interface, in- 
structing TVTRAIN.EXE program to display the charac- 
ter set as shown on Fig. 6D. Both normal and inverse 
(highlighted) characters are shown. At this time, the Vid- 20 
eo CPU enables CRC generation by setting the CRC 
configure latch 429 to the value of hex 83 (which will 
select the two least significant bits and the most signif- 
icant bit of the shift register 439, for feedback 426). 
[0204] The video is then captured producing CRC's 25 
for each character shown on Fig. 6D. Presently there 
are 512 possible characters (256 normal, 256 inverse) 
that may be' displayed on an Host PC's VDM operating 
in a text mode. Some of these characters are duplicates. 
For instance, the zero ASCII code, or null character at 30 
698A, and the hex FF character 698C does not display 
on a VDM and is the same as the space character 698B, 
and will be interpreted as a space (hex 20). Similarly, 
the block character (above the square root sign and near 
698C) is identical to the inverse null 698D and an in- 55 
verse space 698E, and will be interpreted as a block. 
Although, the ASCII codes differ among these two sets 
of characters, the visual information is identical. 
[0205] Only the CRC's for the character sets on Fig. 
6D are presently processed. First, they are checked for 40 
uniqueness (ignoring duplicate or identical characters). 
If they are not unique, then a new value must be written 
to the CRC configure latch 429, such as hex 85, etc. The 
video is again captured and the uniqueness test is re- 
peated. When a suitable value for the CRC configure *s 
latch, which provides for unique CRC codes for all char- 
acters is found, video training continues. 
[0206] If the VDAC is analog (not TTL) then the Video 
CPU instructs the Control to send a key stroke to Host 
PC, via the keyboard interface, instructing TVTRAIN. so 
EXE to enter a 1 6 color 640 by 480 graphics mode and 
display a single horizontal bar at the top of the screen. 
The horizontal and vertical sync polarities are deter- 
mined for this mode and then the video processing cir- 
cuitry is initialized to digitize the video data (the CRC 55 
configure latch 429 is set to zero). The number of hori- 
zontal scan lines 682 preceding any visible pixels is then 
determined. 



[0207] All information gathered during this video train- 
ing process including the pixel timing information and 
character CRC's are transferred to the Control CPU for 
storage in non-volatile RAM. A flag in non-volatile ram 
is then set to indicate the Host Unit has "been success- 
fully trained and the SETUP indicator light 54 is turned 
off. 

[0208] When the training process is complete, the 
Video CPU instructs the Control CPU to send a key- 
stroke to the Host PC, via the keyboard interface, in- 
forming the TVTRAIN.EXE program that training was 
successful. At this point the Host PC returns to it's nor- 
mal operating system (e.g. DOS). 
[0209] Fig. 7 is a block diagram describing the soft- 
ware processing presently occurring within a Remote 
PC. Rectangular objects on this diagram represent soft- 
ware subroutines or menu displays that may be initiated 
within the Remote PC's CPU whenever a program 
(herein referred to as TVLINK.EXE) supplied as part of 
the apparatus is executed. Diamond shaped boxes rep- 
resent major processing decisions occurring within the 
TVLINK.EXE program. Circled boxes with letters inside 
represent either on -page or off-page connectors to the 
next processing step in the block diagram. Lines with 
arrows represent the direction that TVLINK.EXE 
processing flows. 

[0210] TVLINK software is installed on each Remote 
PC that will access Host Site(s). TVLINK.EXE process- 
ing begins at block 700 on Fig. 7A. When the program 
is first invoked, a System Main Menu is displayed 701 
with three processing options. The first menu option, 
Setup System 702, permits configuring the system to 
the user's specific requirements and the hardware con- 
figuration of the Remote PC where the system is being 
installed. The second menu option "Call Host Site" 703 
permits the user to cause their Remote PC to call and 
link to a jjesired Host PC. When this menu option is se- 
lected, a call list of Host Units that may be selected is 
displayed 704. This call list is created and maintained 
as part of Setup System 702 processing. When a Host 
Unit on the list is selected, the program initiates linkage 
processing to the selected Host Site, then links to the 
requested Host Unit. Once linked a password is request- 
ed by the Host Unit using a password transmission key 
based random number that causes the password trans- 
mitted by the Host Unit to be encrypted following a pro- 
cedure set by the key. This approach makes it difficult 
for someone to decode a password being transmitted 
from a Remote PC to a Host Unit by tapping into the 
communication line. If an invalid password is received 
by the Host Unit, a "session" lock out counter for the 
Host Unit is incremented by one. If this counter exceeds 
the limit set for the session (see block 734 processing 
below), the user is locked out from any further access 
attempts to the Host Unit for the current session and a 
Host Unit lock out counter stored in non-volatile RAM in 
the Host Unit is incremented by one. If the Host Unit lock 
out counter exceeds the limit for the Host Unit (see block 
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734 processing below), all access to the Host PC will be 
blocked until someone presses the Action button on the 
front of the Host Unit. 

[0211] If a connection is made to the selected Host 
Unit 705, the TVLINK.EXE program pops up a menu on 
the screen with two choices permitting the Remote user 
to either select a normal access mode or a view only 
access mode. In a normal access mode, the user has 
full keyboard and video access to the Host Unit. In a 
view only access mode, the user has only the capability 
to view the output of the Host PC's VDAC. Next, 
processing continues at block 742. If the Host PC is not 
turned ON or the Host Unit is not properly connected to 
the Host PC, the Host Unit will return an error that no 
Host Video signal is present, but the connection to the 
Host Unit will continue until terminated by the Remote 
User for the possible purpose of retrieving any VDAC 
screen history that may be present in the Host Unit. If a 
connection cannot be completed to a Host Unit 705, an 
appropriate error message appears on the Remote PC 
VDM screen indicating why the connection could not be 
completed and the System Main Menu 701 is redis- 
played. Thefinal System Main Menu option , Exit System 
708 terminates TVLINK.EXE program processing and 
returns control to the Remote PC's operating system. 
[0212] When TVLINK.EXE program is executed for 
the first time on a Remote PC, the Setup System 702 
main menu option is selected first to (1) define whether 
the linkage to a Host PC will be in a Modem Linkage 
mode or Direct Line Linkage mode; (2) setup the Modem 
Specifications and parameters 711 to initialize and ac- 
cess the modem connected to the Remote PC in those 
cases where a Modem Linkage mode will be used; (3) 
setup the Mouse Specifications and parameters 713 to 
define the Remote PC's serial port number where the 
Remote PC's mouse is connected in those cases where 
a serial mouse is present on a Remote PC and will be 
used to control a Host PC; and (4) setup the CALL LIST 
715 of Host Units that may be accessed by the Remote 
PC 71 5. After these initial setup options have been com- 
pleted, the Setup System 702 menu option may be se- 
lected to setup other system configuration options or to 
re-configure any options previously entered. 
[0213] When selected, the Setup Main Menu 710 dis- 
plays a list of four options. The Modem Specifications 
71 1 menu setup option allows the baud rate, serial com- 
munications port number and modem initialization string 
to be defined for the modem connected to the Remote 
PC. If the Remote PC will only operate in a Direct Line 
Linkage mode, then the modem initialization string 
would not be entered. 

[0214] When this option is selected, the software 712 
automatically searches for a Hayes compatible modem 
connected to one of the serial ports on the Remote PC. 
If the modem does not respond to the search, the mo- 
dem's power is turned off (external modem), the cable 
between the Host Unit and modem has not been prop- 
erly connected (external modem), or a serial interrupt 



conflict prevents access to the modem, the Setup proc- 
ess will assume that the Direct Line Linkage mode will 
be used. 

[0215] After the Modem Specifications are entered or 
5 modified, this information is saved on the Remote PC's 
mass storage device. After the baud rate and modem 
reset string are set to desired values, the Esc key may 
be pressed to return to the Setup Main Menu 71 0. When 
the Esc key is pressed and the Modem Linkage option 

10 js specified, the software automatically initializes the 
Remote PC's modem using the baud rate and reset 
string specified. Thereafter, whenevertheTVLINK.EXE 
program, is first initiated, the modem installed in the Re- 
mote PC is initialized automatically, so there is no need 

15 to re-run this menu option again unless the modem in- 
stalled in the Remote PC is changed or the modem does 
not properly connect with a Host Unit. Once all required 
modifications have been made to the Modem Specifica- 
tions, the Esc key may be pressed to return to the SET- 

20 UP menu. 

[0216] The Mouse Specifications menu option 713 
permits specifying the Remote PC's serial port to which 
a mouse is connected. If no serial port number is spec- 
ified, the TVLINK.EXE software assumes that a mouse 

25 is not installed on the Remote PC. Otherwise, the TV- 
LINK.EXE program tests for the presence of a mouse 
on the specified serial port and displays an error mes- 
sage, if the mouse cannot be found by the TVLINK.EXE 
software. Once a valid serial port is specified, the port 

30 number selected is saved to a configuration file on the 
Remote PC's mass storage device, so that subsequent 
TVLINK.EXE sessions will know if and where a mouse 
has been installed on the Remote PC. Once all required 
modifications have been made to the Mouse serial com- 

35 munications port, the Esc key may be pressed to return 
to the SETUP menu. 

[0217]*= The Update Call List 715 menu option permits 
each Host Unit that a Remote PC may access to be de- 
fined or changed 716. Before a call can be placed to 
40 Host Unit, the Host Unit must be defined in the Remote 
PC's call list. 

[021 8] The specific data elements that presently must 
be defined for each Host Unit to be accessed include: 
(1) a location description, which is a user definable al- 

45 phanumeric description of the Host Unit being accessed 
such as "SERVER XYZ", "VAST TAPE Unit", etc. (such 
descriptions help users with access to multiple Host 
Units more easily select a desired Host Unit); (2) a dial- 
ing string needed to call and access the modem at the 

50 site where the Host Unit is located in cases where the 
Remote PC operates in a Modem Linkage mode; (3) an 
alphanumeric password that allows only authorized per- 
sons who have the password to access a specific Host 
Unit; and (4) the ID number of the Host Unit to be ac- 

55 cessed. 

[0219] When a Host Unit is first installed, the default 
password has been pre-set prior to shipment to the eight 
digit serial number of the Host Unit, located on the label 
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affixed to the bottom of the Host Unit. This numeric pass- 
word must be specified in the Remote PC used to initially 
access an newly installed Host Unit. After a Host Unit 
has been successfully accessed using a correct pass- 
word, the password may be changed as described later 
for block 734. 

[0220] New call list entries may be added by using the 
Remote PC's down arrow key to go to the last line of the 
call list which will be a blank line permitting the entry of 
data for the new Host Unit to be accessed. 
[0221] An entry may be deleted from the call list by 
using the Remote PC's keyboard up or down arrow keys 
to highlight the applicable line item and then pressing 
the F3 key to delete the line from the call list. 
[0222] A call list entry may be changed by highlighting 
the applicable line item, then changing the data con- 
tained on the line, as desired. Various other keys may 
be pressed to speed the process of navigating through 
a cali list. A list of these keys is displayed in a pop up 
window whenever the user presses the F1 key. The pop 
up window is removed from screen when the user press- 
es the Esc key. 

[0223] Once all required modifications have been 
made to the call list, the Esc key may be pressed to re- 
turn to the Setup Menu. 

[0224] The last menu option on the Setup Main Menu 
710, Return To Main Menu 719, permits returning to the 
appropriate System Main Menu VDM screen as dis- 
cussed below beginning at block 742. 
[0225] The "Connection Options" menu line only ap- 
pears on the Host System Main Menu 755 when a active 
linkage exists between the Remote PC and a Host Unit. 
When selected the Connection Options Main Menu 720 
is displayed that presently contains various processing 
options. 

[0226] The Scan Screen History 721 connection 
menu option permits Host VDM screen data captured 
and transmitted to a Remote PC's VDM during a linkage 
session to be reviewed 722. 

[0227] When the Remote PC is linked with a Host PC, 
all video VDM screen data received from the Host Unit 
is automatically logged to a screen history data file on 
the Remote PC presently called SCRNHIST.DAT. This 
file is automatically cleared whenever TVLINK.EXE 
processing is first initiated. 

[0228] When the Display Screen History connection 
menu option is selected, the TVLINK.EXE program au- 
tomatically activates a VIEWHIST.EXE subroutine to 
view the SCRNHIST.DAT file for the current TVLINK. 
EXE processing session. This permits any VDM screen 
data captured since the TVLINK.EXE program was ini- 
tiated to be reviewed. The VDM screen history can be 
reviewed by using the UP and DOWN arrow keys. The 
Esc may be pressed to return to the Connection Options 
main menu 720. 

[0229] The Color Mode 723 connection menu option 
is selected to set the active Host Unit to a specific color 
or monochrome display mode for purposes of capturing 



VDAC output for transmission to a Remote PC. 
[0230] Five menu options are displayed when the 
Color Mode 723 menu option is selected, which are (1 ) 
Normal Color Mode, (2) Bright Color Mode, (3) Green 
5 Signal Mode, (4) Red Signal Mode, and (5) Blue Signal 
Mode. These menu options give a Remote userthe abil- 
ity to either transfer VDAC text output to a Remote PC 
in normal intensity or high intensity color or in a mono- 
chrome mode using either the Red, Blue or Green signal 
10 as the basis for decoding the VDAC output. In the high 
intensity color mode, the foreground colors are dis- 
played from the high intensity color set and the back- 
ground color set remains normal. 
[0231] Normally the Host Unit is in a default display 
15 mode where the Host Unit's Video Processor only looks 
at the green color signal output of the VDAC. This mode 
is one of three possible monochrome modes and nor- 
mally yields the fastest possible video processing and 
the greatest probability of decoding video text data dis- 
played by a color VDAC and the green signal is the only 
signal for some monochrome VDAC output. Blue and 
Red Signal Modes also yield the fastest possible video 
processing, but selecting these modes may cause a 
lower probability of decoding either the Blue or Red sig- 
nals into characters because Host PC color applications 
typically use the Blue or Red signals less often than the 
green signal. 

[0232] Selecting either the Normal or Bright Color 
Modes slows down the Video CPU which must decode 
multiple signals in order to determine color and the text 
character. As a result, text data may not appear as 
quickly on a Remote PC, when either color mode is se- 
lected. However, selecting color assures the highest 
probability that the text data output of a VDAC will be 
properly decoded. 

[0233] Presently, for graphics modes only the green 
VDAC oi4put signal is used regardless of the menu op- 
tion selected. As previously mentioned adding addition- 
al hardware to the Host Units Video Processor circuitry 
would permit multiple color graphics transfers to a Re- 
mote PC in a reasonable period of time. 
[0234] The UP and DOWN arrow keys may be used 
to change to a desired color or monochrome display 
mode and then the Enter key may be pressed to select 
that mode. 

[0235] After the desired display mode option is select- 
ed off of the menu orthe ESC key is pressed, processing 
is returned to the Connection Options menu 720. 
[0236] The Switch Host/Remote Mode 725 connec- 
tion menu option is selected to set the mode that will be 
active after exiting from the main system menu when a 
connection to a Host Unit is active. Whenever TVLINK. 
EXE processing is first initiated, Host mode processing 
is assumed. 

[0237] A menu 726 containing two possible modes 
appear when the Switch Host/Remote Mode 725 menu 
options is selected. The desired mode is highlighted us- 
ing the Up and Down keyboard arrow keys and then the 
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Enter key is pressed to select the mode. 
[0238] If the Remote menu option is selected, the last 
menu option on the system main menu will be changed 
from "Exit to Host mode" to "Exit to DOS" after exiting 
from the Connection Options Main Menu 720. On this 5 
basis, selecting Exit to DOS option causes Remote PC 
processing to temporary exit out of the TVLINK. EXE ap- 
plication to the PC's operating system (e.g. DOS) while 
continuing to maintain a connection to the Host Unit. 
Once DOS processing has been completed, a user may 10 
then return to the system main menu by typing "EXIT" 
at a DOS prompt. For example, shelling-out to DOS dur- 
ing a TVLINK.EXE session would be useful if it became 
necessary to locate the directory where a file is located 
in order to transfer the file to a Host PC. 15 
[0239] If the Host menu option is selected, the last 
menu option on the TVLINK.EXE menu will be "Exit to 
Host mode". When a Remote PC is placed in a Host 
mode, the Remote PC assumes control of the Host PC. 
In this mode, the contents of the Remote PC's VDM 20 
screen reflect the contents of the Host PC's VDM screen 
and the Remote PC's keyboard and mouse (assuming 
the mouse option is installed) is redirected to input key- 
strokes/mouse data to the Host PC, as opposed to the 
Remote PC. Accordingly, because the Remote key- 25 
board, mouse and VDM act as if the remote user is sit- 
ting at the Host PC, there needs to be a sequence and/ 
or combination of keystrokes (i.e. hot key) pre-defined 
that will cause the Remote PC to return back to a normal 
operating mode. Presently, tapping the left Shift key 30 
three times within 2 seconds acts as this hot key causing 
the Remote PC to return back to a normal operating 
mode. In this same regard, if a user taps the right Shift 
key two times within two seconds while in a Host mode, 
it will refresh the Remote PC's VDM screen by causing 3s 
the Host Unit to transmit the entire current contents of 
the Host PC's screen. Normally, the Host Unit only 
sends any changes that have occurred on the Host PC's 
screen to minimize the amount of data transmitted to a 
Remote PC. On occasion, variances in the Host PC's 40 
VDAC signals may cause the Host Unit to mis-interpret 
data displayed on a screen and send corrupted display 
data to a Remote PC. Tapping the right Shift key twice 
refreshes the Remote PC's VDM screen. 
[0240] Normally, when a Remote PC is in a Host <s 
mode, all key strokes entered into the Remote PC's key- 
board are intercepted by the TVLINK.EXE program and 
transmitted to the Host Unit, so that the Host PC can 
pass these keystrokes on to the Host PC. This process 
also permits the TVLINK.EXE to take other actions so 
when necessary. As previously mentioned, multiple taps 
of the left or right shift keys presently cause the TVLINK. 
EXE program to pop up and activate TVLIN K. EXE menu 
processing. In addition, when the "Print Screen" key is 
pressed, TVLINK.EXE presently permits this keystroke ss 
to pass through to the Remote PC's operating system, 
thereby permitting the Remote PC to print the contents 
of a Host PC's VDM screen to a printer connected to the 
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Remote PC. Other such processing exceptions can be 
made where necessary (through appropriate changes 
to the TVLINK.EXE program code) to further enhance 
a Remote user's ability to more effective manage both 
their Remote PC's and Host PC's resources. 
[0241] When a user is in a Host mode and presses 
the left Shift key three times within two seconds, the user 
is returned to the System Main Menu 741. This menu 
and other menus pop-up (i.e. overlay) over a portion of 
the Host PC's screen. Any Host VDM information dis- 
played continues to be updated and visible behind the 
pop-up menu on the Remote PC's VDM screen until the 
Host PC's connection is terminated or the user tempo- 
rarily exits to the PC operating system (e.g. DOS) as 
explained at blocks 753 and 754. 
[0242] After either the Host or Remote option is se- 
lected, processing is returned to the Connection Options 
menu 720. 

[0243] The File Transfer 727 connection menu option 
is selected to permit data file transfers to occur between 
the Host PC and Remote PC. File transfers from one 
directory location on a Remote PC to another directory 
location on the Remote PC can be accomplished by 
temporarily exiting to the PC's operating system, as de- 
scribed under the narrative for block 726 above. File 
transfers from one directory location on a Host PC to 
another directory location on the same Host PC can be 
accomplished by selecting the "Exit to Host" option off 
of the system main menu, then using the Remote key- 
board (that has been redirected to operate in place of 
the Host PC's keyboard) to complete the transfer using, 
for example, the DOS COPY command. 
[0244] In order to complete any file transfer between 
a Host and Remote PC, the Host Unit must have been 
properly connected to one of the Host PC's serial ports. 
When this file transfer option is selected, a menu con- 
taining-^wo options appears that define the direction of 
the file transfer 728. The first option permits file transfer 
to occur from the Remote PC to the Host PC. The sec- 
ond option permits file transfers to occur from the Host 
PC to the Remote PC. File transfer processing may be 
aborted by pressing the Esc key. If the Esc key is 
pressed, processing will return to Connection Options 
Menu 720. 

[0245] Once the direction of the file transfer has been 
selected, the entry of the file specification is required to 
define the file(s) to be copied. This specification is pres- 
ently set to follow the normal DOS COPY command for- 
mat used to describe a source file to be copied. For ex- 
ample, the source file could be specified as C:\NET- 
WAREV.EXE, C:VREPAIR.COM, or XNETWAREWRE- 
PAI R.COM . Once the source file has been specified, the 
entry of the target drive and full directory path where the 
files will be copied is presently required. 
[0246] After the source files and target location have 
been specified, file transfer processing is initiated auto- 
matically using a file transfer protocol such as XMO- 
DEM, which is known to persons familiar to the trade. 
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. File transfer processing is aborted if (1) the Esc key is 
pressed, (2) no source files exist or the source file drive 
and/or directory is invalid, (3) the Host Unit is not prop- 
erly connected to an active, available, Host PC serial 
port, or (4) the target drive and/or directory do not exist. 5 
Should processing be aborted an appropriate error mes- 
sage will be displayed and processing will return to the 
Connection Options Main Menu 720. Otherwise, during 
the file transfer process, the name of each file being 
transferred will be displayed. to 
[0247] After a desired file transfer process has been 
completed, processing is returned to the Connection 
Options Main Menu 720. 

[0248] The Cold Boot Host 729 connection menu op- 
tion is selected to temporarily interupt all AC power to 15 
the active Host PC for approximately 15 seconds. A 
Host PC cannot be cold booted unless the Host PC's 
AC power plug is plugged into the AC Out receptacle on 
the back of the Host Unit. 

[0249] When this menu option is selected, the cold- 20 
boot request must be confirmed by entering "Y" in re- 
sponse to the question "ARE YOU SURE? (Y/N)" 730. 
If "N" is entered in response to the question, cold-boot 
processing is aborted and processing returns to the 
Connection Options Main Menu 720. If "Y" is entered, 25 
the Remote PC sends instructions to Host Unit to tem- 
porarily cut AC power to the Host PC for approximately 
15 seconds. -Once the power is restored, the Host PC 
reboots, the Host Unit returns a confirmation to the Re- 
mote PC that the cold boot process has been completed 30 
and processing returns to the Connection Options Main 
Menu 720. 

[0250] The Switch To New Unit 731 connection menu 
option is selected to switch from one Host Unit on a daisy 
chain to another Host Unit on the same daisy chain with- 35 
out terminating the linkage between a Remote PC and 
a Host Site. 

[0251] If only the currently active Host Unit at a Host 
Site is accessible, there is no reason to select the Switch 
To New Unit menu option. In cases where it is desired 40 
to switch from one Host Unit to another Host Unit at a 
different Host Site, the currently active modem linkage 
must be terminated by selecting the Terminate Call 
menu option 737, then establishing a new connection to 
the desired new site, as described beginning at block 45 
703. 

[0252] When the Switch To New Unit 731 option is se- 
lected, a call list containing all Host Units defined using 
the same phone dialing string is displayed 732. 
[0253] The list of Host Units are displayed to permit so 
switching between Host Units daisy chained together 
without the need to terminate the existing phone line 
connection. The Esc key may be depressed to avoid 
switching to another Host Unit and return to the Con- 
nection Options Main Menu 720. The UP or- DOWN ar- ss 
row keys can be used to scroll through the list of Host 
Units defined. Once the desired Host Unit has been 
highlighted, the Enter key can be pressed to switch to 



the new Host Unit. 

[0254] If the new Host Unit is inaccessible or the pass- 
word used for the new Host Unit is incorrect, an appro- 
priate error message will be displayed on the Remote 
PC's VDM screen, the connection to the fast active Host 
Unit will be restored and processing will return to the 
Connection Options Main Menu 720. Otherwise, the ac- 
tive connection will be switched to the requested Host 
Unit and processing will be returned to the Connection 
Options Main Menu 720. 

[0255] When the Change Unit Password option is se- 
lected 733, the system requests the entry of a new pass- 
word for the currently active Host Unit 734. The Change 
Unit Password option permits changing the currently ac- 
tive Host Unit's password to a new password. When the 
password is changed, the call list entry forthe applicable 
Host Unit is automatically updated to reflect the new 
password. Presently, when a Host Unit is manufactured, 
the password is initially set as the Host Unit's serial 
number. 

[0256] . When the Change Unit Password option is se- 
lected, the user is requested to enter a new password 
of up to eight digits in length. Password change process- 
ing may be aborted by pressing the Esc key. When the 
Esc key is pressed, processing returns to the Connec- 
tion Options Main Menu 720. Otherwise, after a new 
password is entered, the Host Unit is updated for the 
new password. 

[0257] Afterthe password has been updated, the user 
is requested to enter any changes to the number of at- 
tempts during a session that a user is given to enter a 
valid password before being locked-out of this Host Unit 
for the session. An entry of zero indicates that a user 
may be given an unlimited number of attempts to enter 
a valid password to access the Host Unit. For purposes 
of lock out processing, a session refers to the period 
between^fhen a remote user first connects to a host site 
until that time the remote user terminates the connection 
to the site. 

[0258] Once the number of password attempts during 
a session has been updated, the user is requested to 
enter the n umber of concurrent sessions that may occur 
where a user fails to specify a correct password when 
accessing this Host Unit and is locked out of the Host 
Unit for the session. If the number of concurrent access 
lock-ups exceeds the specified number, the Host Unit 
will be electronically locked, until someone presses the 
action button on the front of the Host Unit. When a Host 
Unit is electronically locked, any user attempting to ac- 
cess the Host Unit will be given a message that the Host 
Unit was locked due to a possible intruder and access 
will be denied even if a valid password is entered until 
the Action button on the front of the Host Unit is pressed. 
Also, when a Host Unit is electronically locked, the Host 
Unit will emit a periodic audible alarm sound indicating 
the Host Unit is locked until the action button on the front 
of the Host Unit is pressed. An entry of zero indicates 
that the Host Unit should never be electronically locked. 
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Whenever a Host Unit is successfully accessed by a Re- 
mote user, the concurrent session lockout counter is re- 
set to zero. 

[0259] Both the session lock and. electronic lock are 
security measures designed to prevent giving a means 5 
to unauthorized intruders to guess a password to a Host 
Unit by limiting the number of guesses they can make 
and bringing the unauthorized access attempts to the 
attention of management via the electronic lockout pro- 
cedure. 10 
[0260] After, the password and related access counts 
are entered, the applicable call list entry is updated to 
reflect the new password, and processing returns to the 
Connection Options Main Menu 720. 
[0261] When the Change Temporary Password op- is 
tion is selected 735, the system requests the entry of a 
new temporary password for the currently active Host 
Unit 736. 

[0262] In some cases it may be necessary to grant 
someone temporary access rights to a Host Unit. For 20 
example an independent network consultant at a remote 
site may need to temporarily access a file server to fix 
an unusual network problem. 

[0263] When the Change Temporary Password 735 
menu option is selected, a user may specify an addition- 25 
al "temporary" password and a number of hours that the 
password should remain in effect. The temporary pass- 
word entry may be aborted by pressing the Esc key. If 
the Esc key is pressed, processing returns to the Con- 
nection Options Main Menu 720. Otherwise, after a new 30 
temporary password is entered, the Host U nit is updated 
for the new temporary password, number of hours the 
password will remain in effect, and then processing re- 
turns to the Connection Options Main Menu 720. 
[0264] The Terminate Call 737 connection menu op- 35 
tion is selected to terminate the linkage to a Host site. 
When Terminate Call 737 menu option is selected, the 
call termination request must be confirmed by entering 
■Y" in response to the question "ARE YOU SURE? (Y/ 
N)" 738. If "N" is entered in response to the question, 40 
call termination processing is aborted and processing 
returns to the Connection Options Main Menu 720. If "Y" 
is entered, the connection to the Host site is terminated 
causing both the Host and Remote modem to be reset, 
when in a Modem Linkage mode, and processing re- 45 
turns to the System Main Menu 701 . 
[0265] The Clear Screen History 739 connection, 
menu option is selected to clear all screens captured 
and stored on the Remote PC's mass storage device 
since TVLINK.EXE processing was initiated or the so 
screen history file was last cleared during an active ses- 
sion. 

[0266] When the Clear Screen History 739 menu op- 
tion is selected, the clear screen history request must 
be confirmed by entering "Y" in response to the question 55 
"ARE YOU SURE? (Y/N)" 740. If "N" is entered in re- 
sponse to the question, clear screen processing is 
aborted and processing returns to the Connection Op- 
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tions Main Menu 720. If "Y" is entered, the screen history 
file is deleted, a new empty screen history file is created 
and processing returns tothe Connection Options Main 
Menu 720. 

[0267] The Select Mouse Mode menu option 740A 
connection menu option is selected to activate or deac- 
tivate recognition of a mouse connected to the Remote 
PC. When this menu option is selected, two menu op-, 
tions appear 740B permitting the user to instruct the TV- 
LINK. EXE software to either recognize or ignore mouse 
movements from the mouse connected to the Remote 
PC for purposes of transmitting the mouse movement 
data to control the Host PC. 

[0268] The Return To Main Menu 741 connection 
menu option is selected to return to the system's main 
menu or is automatically invoked if the connection to a 
Host Unit is lost. The processing options displayed on 
the system's main menu vary depending on the process- 
ing status and the Remote/Host mode status 726. If a 
connection between a Remote Site and a Host site is 
lost due to a communications failure during connection 
options menu processing 742, processing returns to the 
System Main Menu at block 701 . Otherwise, if the sys- 
tem is in a Host mode 743, Host Mode Main Menu 
processing is initiated beginning at block 755. If the sys- 
tem is in not in a Host mode 743, Remote Mode Main 
Menu processing is initiated beginning at block 750. 
[0269] Remote Mode Main Menu processing begins 
at block 750. This menu includes three processing op- 
tions. If the Setup System processing option 751 is se- 
lected, Setup Main Menu processing begins at block 
710. If the Connections Main Menu option is selected 
752, connection option processing begins at block 720. 
If the EXIT TO DOS option is selected 753, control is 
returned to the PC's operating system (e.g. DOS, Win- 
dows™, etc.) until the Remote user key enters "EXIT* 
754. A&erthe user enters "EXIT" processing returns to 
the Remote Mode Main Menu 750. 
[0270] Remote Mode Main Menu 750 processing is 
terminated automatically if the communication connec- 
tion between a Remote PC and a Host PC is lost 754A 
(e.g. due to a phone line failure) and processing is re- 
turned to the System Main Menu 701. Otherwise, Re- 
mote Mode Main Menu processing continues until either 
the Host Unit connection is terminated 738 or the mode 
is switched to a Host mode 726 during Connection Op- 
tions Main Menu Processing 720. 
[0271] Host Mode Main Menu processing begins at 
block 755. This menu includes three processing options. 
If the Setup System processing option 756 is selected, 
Setup Main Menu processing begins at block 710. If the 
Connections Main Men u option is selected 757, conn ec- 
tion option processing begins at block 720. If the Exit To 
Host Mode option is selected 758, the Remote PC's key- 
board, mouse (assuming a mouse is installed on the Re- 
mote PC and activated as described at block 740B) and 
VDM display are redirected to control the Host PC's key- 
board/mouse and display the Host PC's video output 
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761 until the Remote user taps the left Shift key three 
times within two seconds, as previously discussed at 
block 726. When the user taps the left shift key 3 times, 
processing returns to the Host Mode Main Menu 755. 
[0272] When a Remote PC is in a Host Mode the Re- 
mote PC's screen mode automatically switches to the 
screen mode (e.g. text or graphics) presently active on 
the Host PC. If the active screen mode is not supported 
by the TVLINK.EXE program or the Remote PC's 
VDAC, a error message indicating the Host PC has an 
unsupported video mode appears on the Remote PC. If 
during the course of accessing a Host PC, the screen 
mode should change, the Host Unit would automatically 
notify the Remote PC that a change has occurred to a 
new video mode and then wait for a response from the 
Remote PC to confirm the Remote PC VDAC has been 
switched to the new video mode before further video da- 
ta transfers occur. 

[0273] Host Mode Main Menu 755 processing is ter- 
minated automatically if the communication connection 
between a Remote PC and a Host PC is lost 760 and 
processing is returned to the System Main Menu 701. 
Otherwise Host Mode Main Menu processing continues 
until either the connection is terminated 738 or the mode 
is switched to a Remote mode 726 during Connection 
Options Main Menu Processing 720. 
[0274] Figures 8A and 8B show examples of the cur- 
rent protocol implemented between the Host Unit and 
the TVLINK.EXE program running on a Remote PC. Nu- 
merous alternative approaches known to those of skill 
in the art could have been chosen to implement a pro- 
tocol for the apparatus. 

[0275] Values used in the protocol are shown as hex- 
adecimal numbers. Initially, once a modem connection 
has been established between the Remote PC and the 
Host Unit 00, all Host Unit's at a site constantly monitor 
data from the TVLINK. EXE program waiting for a correct 
access request addressed to their Host Unit's ID. 
[0276] Reference 807 represents data which the TV- 
LINK.EXE program sends to the Host Unit. Reference 
806 represents data which the Host Unit sends to the 
TVLINK.EXE program. The TVLINK.EXE program ac- 
cesses a given Host Unit by sending a four byte packet 
as shown at references 800, 801. The first two bytes 
(hex 70 and hex 00) indicate that access is requested, 
and is followed by two bytes which contain the request: 
ed unit's identification number. This number is split into 
two 4 bit quantities (nibbles): Hex 40 plus the high nibble 
(shifted down 4 bits) and hex 50 plus the low nibble. The 
Host Unit on the chain with a matching identification 
number will respond by unchaining and directly connect- 
ing to the data line. This Host Unit then requests a pass- 
word from TVLINK.EXE program on the Remote PC. 
[0277] A hex FF 802 is reserved as a BREAK charac- 
ter. When this character is received, it indicates that the 
next byte is a command or status byte. The hex 06 fol- 
lowing 802 is a request for password and is followed by 
two bytes 803 which form an encryption. The TVLINK. 



EXE program then sends an encrypted password 804 
to the Host Unit. If this encrypted password is correct, 
the Host Unit sends hex FF and hex 1 0 bytes 80{> which 
means that the Host Unit is ready and that the Host Unit 
5 has been successfully accessed. 

[0278] Although only one password is requested as 
shown in the figure, in the current implementation, three 
to a ten passwords will be processed each with a unique 
encryption key. Only after all passwords are correctly 
10 received will the Host Unit send the ready status 805. 
This password protocol approach insures added secu- 
rity to the Host Unit access. If a password is incorrect, 
then no more password requests will occur and the Re- 
mote PC will not be permitted access to the Host Unit. 
*s [0279] To avoid inadvertent access to other Host 
Unit's while having access to a given Host Unit, hex 70 
is never transmitted to the Host Unit by TVLINK.EXE 
program (other than during an access request 800). In- 
stead, the two byte packet 810 is sent which is interpret- 
ed as a single byte value of hex 70. 
[0280] Reference 827 represents data which the TV- 
LINK.EXE program sends to the Host Unit Reference 
838 represents data which the Host Unit sends to the 
TVLINK.EXE program. After the host sends the ready 
status 805, the TVLINK.EXE program can now issue 
commands to the Host Unit. 

[0281] To enter remote access in text mode, the two 
byte command packet 820 is sent. It is composed of the 
BREAK character (hex FF) and the command byte (hex 
33). The Host Unit now begins a remote access mode. 
In this mode, data bytes sent to the Host Unit from the 
TVLINK.EXE program are interpreted as keyboard scan 
codes which are translated and sent to the Host PC as 
keyboard signals. The hex value 1 E at 821 is a scan 
code generated when the 'A' key is pressed. The hex 
value 9E at 822 is a scan code generated when the 'A' 
key is re&ased. 

[0282] Also, in remote access mode, video text data 
is captured and sent to the TVLINK. EXE program 838. 
This video data stream is composed of several parts. 
First, the screen character address is sent, which is the 
BREAK character 830 plus the two byte address 831 . 
This address 831 is shown as zero, but since it is as- 
sumed upon entering remote access mode that the Re- 
mote PC's monitor screen has been blanked by the TV- 
LINK.EXE program for the first screen's worth of data, 
no spaces will be sent. Thus, this starting address 831 
may not necessarily be zero but will indicate the address 
of the first non-blank character encountered. 
[0283] Next, color attribute information is sent (the 
BREAK character 832 with the attribute 833). This at- 
tribute byte is a hex CO value summed with the 6 bit color 
attribute. Each bit can be represented by the form of 
"UrgbRGB" where the two most significant bits "11" 
(one.one), indicate that this is a color attribute byte 
where r,g and b represent red, green and blue fore- 
ground color bits, and R, G, and B represent the back- 
ground color bits, as more fully discussed in the narra- 
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tive supporting Fig. 5G and 5H. The value shown at 833 
(hex F8) represents white on black. The two most sig- 
nificant bits (hex CO) is masked off (set to zero) leaving 
hex 38 or 001 1 1 000b. All foreground bits (rgb) equal one 
and all background bits (RGB) are zero, thus meaning 
white on black. 

[0284] Afterthe address and color information is sent, 
character code values, such as ASCII codes, follow. 
Reference 834 shows the hex representation of an "A" 
followed by a hex 42 which represents a "B" character. 
After this, there is a color change, so 835A is sent, com- 
posed of a BREAK character and the new color byte. In 
this case the hex F1 represents blue on black. The two 
most significant bits (hex CO) is masked off (set to zero) 
leaving hex 08 or 00001 000b. Only the foreground blue 
bit (rgb) is equal to one and all background bits (RGB) 
are zero, thus blue on black. After this a hex 43 repre- 
senting a "C" character is sent 835B. This continues un- 
til and an entire screen's worth of data is sent after which 
only the changes will be sent (thus reference 831 may 
take on non-zero values). Hex value FF, used in this 
mode at 838, as the break character, was selected be- 
cause this value does not represent a valid character. 
[0285] In addition to the scan codes 821, 822 being 
sent by TVLINK.EXE program to the Host Unit 827, 
there are several commands which can also be sent. A 
refresh-screen command (hex F1) 823 instructs the 
Host Unit to res end an entire screen of video text as if 
remote access mode has just been invoked. This begins 
with another address packet 836 (identical to 830) to be 
sent followed by color information, then characters, etc. 
[0286] Another type of command 824 sends serial 
mouse data 825 to the Host Unit to be forwarded to the 
Host PC's serial mouse input port. The content of this 
mouse data 824 in not important to either the TVLINK. 
EXE program or the Host Unit, it is simply passed 
through to the Host PC's serial mouse port. 
[0287] As the Host Unit is capturing video text data, 
the Host PC's video mode may change to graphics 
mode at which pointthis information is transmitted to the 
TVLINK.EXE program as indicated at reference 837 (a 
BREAK character plus the graphics mode status: hex 
83). At this point, the Host Unit will not send any more 
video text information, but will continue to process scan 
codes and commands received from the TVLINK.EXE 
program. In the current implementation, the TVLINK. 
EXE program will end remote access text mode by is- 
suing a hex FF 826 (which in this usage, is not a BREAK 
character) and begin remote access graphics mode. 
Then, the Host Unit sends a ready status (see 805) to 
indicate it is ready to process another command. 
[0288] Remote access graphics mode begins by the 
TVLINK.EXE program sending 840 (a BREAK character 
.plus a hex 34 remote access graphics command). At 
this point the Host Unit sends video graphics data 855 
and will process scan codes, mouse information or other 
commands 846. Scan codes are shown at references 
841 , 842, the refresh command causing the graphics 



screen to be "re-painted" is shown at 843, and the end 
graphics video mode command shown at 845. Mouse 
data is not shown but can also be processed. 
[0289] The primary difference between graphics 
5 processing and text processing, is thatthe BREAK char- 
acter value is now a hex 2A. This value was chosen be- 
cause a hex FF, which means all pixels are on, is a com- 
mon occurrence in graphics mode, so the value hex 2A 
was chosen instead. This mode begins by sending the 
10 starting address (the break character 850 with two bytes 
of graphics address information 851). It is assumed that 
the Remote PC's display screen is blank, and so only 
non-zero graphics data bytes are sent. The address val- 
ue 851 may be other than the zero value shown. 
15 [0290] In the most preferred embodiment, only graph- 
ic "snap shots" are taken. That is, after the address is 
sent, and the graphics data 852 has been completely 
sent, video graphics data will cease, until a refresh 
screen command 843 is received, at which time the 
20 graphics data is captured and sent again (see 853). Ref- 
erence 854 shows that the Host PC's video mode has 
changed back to text mode (a break character plus the 
text mode status, hex 85). Then, the TVLINK.EXE pro- 
gram will end remote graphics mode via 845 and start 
the remote text mode (see 820). Note that for the remote 
graphics mode, if a graphics data byte equals a hex 2A 
(same as the break character) then a two byte packet is 
sent, which includes the break character (hex 2A) fol- 
lowed by the hex value A2. The TVLINK.EXE program 
will interpret this to be a hex 2A data byte. 
[0291] Either the text or graphics mode can be ended 
at any time by issuing the hex FF character 826,845. 
[0292] It is possible that the video mode may change 
to an unrecognized video mode or video may cease al- 
together (i.e. by turning the Host PC off or disconnecting 
the video cable). TVLINK.EXE is notified of this event 
(simila^to 837 and 854) by sending a BREAK character 
followed by a hex 89 (no video present) or hex 8B (un- 
known video mode). 

[0293] The file transfer mode is entered in a fashion 
similar to the video modes just described (i.e. a BREAK 
character followed by the command byte). The Host Unit 
simply passes TVLINK.EXE file data through to the Host 
PC or vice versa after the TVFILE.EXE program has 
been invoked on the Host PC to handle file transfers. 
The TVLINK.EXE converts all (Host Unit bound) hex 70 
values to the two byte packet shown at 810 which the 
Host Unit will convert to a single hex 70 value before 
sending it to the Host PC. If TVLINK.EXE sends a hex 
FF character, this will end file transfer mode. So, (Host 
PC bound) data values of hex FF must be converted to 
a two byte packet of hex F0 plus hex OF 81 1 , which the 
Host Unit will convert to a single value of hex FF before 
sending it to the Host PC and TVFILE.EXE program. 
Other than these exceptions, the file transfer protocol is 
the responsibility of the TVLINK.EXE and TVFILE.EXE 
programs. In the current implementation, a modified 
XMODEM protocol is employed for file transfers with the 
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data packet size changing according to the number of 
errors encountered (line noise). The XMODEM protocol 
is an industry standard familiar to persons in the trade. 
[0294] The current Host Unit protocol could be modi- 
fied to employ a higher level of data transmission error 
detection and acknowledgment to lessen the possibility 
of communication line noise causing data errors. 
[0295] Fig. 9 represents an alternative embodiment of 
the present invention to the preferred embodiment dis- 
cussed above in which a Host Unit captures and de- 
codes the Host PC's VDAC video raster output signal. 
Under this approach, an Expansion adapter Card (EC) 
could be inserted into one of the available interface 
adapter card buss slots (e.g. 16 or 32 bit slots) within 
the Host PC and capture the digital video data directly 
from the Host PC's buss as it is being send to the Host 
PC's VDAC. In this case the EC would be designed so 
as not to interfere with normal Host PC processing, but 
would simply "listen-in" on the Host PC's buss and im- 
mediately transmit any video data detected to the Host 
Unit via a direct cable linkage between a Host PC video 
data interface (e.g. serial) port and a Host PC interface 
port on the EC. 

[0296] As shown on Fig. 9, a possible embodiment of 
the EC would contain it's own microprocessor 902. Op- 
erating system software (within the associated EPROM 
memory 901) would monitor video activity being sent to 
the Host Unit's VDAC. Any video data detected on the 
buss 910 would be sent out through the EC's video data 
output receptacle 903 to the Host Unifs 904 (via a video 
data input receptacle) via 903. Because of possible dif- 
ferences in data transmission rates between the speed 
of the Host PC's buss and the speed at which data can 
be transmitted to a Host Unit, two levels of data buffering 
is included. To capture the video data from the Host PC's 
buss 910, several first-in first-out (FiFO's) buffers 912, 
914, 91 6 would be used. The microprocessor then reads 
from these FIFO's, processing the data to place it in a 
form ready for transmission, and stores this data in 
memory 900. The data in this memory is then transmit- 
ted to the Host Unit. The EC contains battery back-up, 
so that any data existing in the buffer could continue to 
be transmitted by the EC to the Host unit even in cases 
where the Host Unit has failed. 

[0297] Digital video data received from the EC by the 
Host Unit would be stored in the Host Unit and forwarded 
to the Remote PC following the same procedures de- 
scribed for the preferred embodiment. However, the 
Host Unit would no longer need to access and decode 
the VDAC output from the Host PC, since in this alter- 
native embodiment the digital video data would be sup- 
plied by the Host PC's EC. 

[0298] Standard VDAC memory usage is as follows. 
This memory (addressed by the Host PC's microproc- 
essor) resides on the VDAC. Monochrome-text data is 
written to memory addresses starting at B000:0000. 
Whereas color text data is written to addresses starting 
at B800:0000. Standard VGA mode color graphics data 



is written to addresses starting at A000:0000 and this 
represents a 64K block (which is not large enough for 
VGA) and is bank switched to allow total access to the 
entire VDAC graphics memory. Bank switching is ac- 
5 complished by writing certain data bytes "to VDAC port 
addresses. 

[0299] When data is written to the VDAC's video 
memory, whether in text mode or graphics mode, this 
data will also be written to the EC's FIFO's. The Host 

10 PC's 20 bit buss address is split between two FIFO's. 
The 16 bit buss data value 911 will be written to FIFO 
91 2. The 1 6 bits of the buss address 91 3 are also written 
to FIFO 914. The remaining 4 bits of the buss address 
combined with certain control signals 915 are written to 

15 FIFO 916. These control signals are composed of a sin- 
gle-byte access line and its associated high or low byte 
line, the write port signal, and the write memory signal. 
These signals 91 5 are analyzed (not shown) so that data 
will be written to the FIFO's only when addresses A000: 

20 0000 through BFFFiFFFF, as well as VDAC port ad- 
dresses, are written to by the Host PC's buss. Note that 
Fl FO's need not be used and could be replaced by other 
circuitry to accomplish the same function. 
[0300] The three FIFO's are then read by the micro- 
ns processor 902 and analyzed to determine the kind of 
VDAC access, and writes appropriate output data to the 
memory 900. This memory is treated as a circular buffer. 
When the buffer is not empty, then data is sent via 903 
to the Host Unit 904. Thus, new data is added by 902 

so when it is received from the FIFO's, while previously 
processed data is forwarded to the Host Unit. 
[0301] As an alternative embodiment to a separate 
EC, the functions of the separate EC could be incorpo- 
rated on to a single Host VDAC. In this case the combi- 

35 nation VDAC would have two output ports, namely a 
VDM interface port and a Host Unit interface port for 
transmittisg the digital video information from the Host 
PC to the Host Unit via an interface cable. 
[0302] An alternative embodiment of the Host Unit 

40 permits the Host Unit to be more portable and easily 
connectable to a Host PC in cases where one Host Unit 
was used to facilitate access to more than one Host PC. 
This alternative embodiment is hereinafter referred to 
as a "Portable Host Unit". A Portable Host Unit would 

45 typically only be connected to a Host PC in cases where 
one of the Host PC's at a Host Site had failed and a 
repairman needed temporary access to the failed Host 
PC remotely to initiate repairs. Once the repairs were 
completed or the problem with the Host PC diagnosed, 

50 the Portable Host Unit could be removed from Host PC 
and remain at the Host site until another PC failed. 
[0303] Under one possible alternative embodiment of 
the Host Unit, a buss interface slot could be incorporated 
into the internal circuitry of the Portable Host Unit. This 

55 slot could then permit a standard internal modem (com- 
monly inserted into PC buss slots and familiar to per- 
sons in the trade) to be inserted into the Portable Host 
Unit and thereby eliminate the need for an.external mo- 
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dem. This approach eliminates the extra steps required 
for personnel at the Host Site to hook up an external 
modem to effect remote access. In addition, the Porta- 
ble Host Unit would have an acoustical coupler (familiar 
to persons familiar with the trade) which would be incor- 
porated into the Portable Host Unit's case and connect- 
ed to the Portable Host Unit's internal modem to permit 
a standard telephone headset to be used (instead of a 
standard telephone line) to connect a Remote PC to the 
Portable Host Unit. An acoustical coupler connection is 
preferred over a telephone line connection due to the 
existence of intelligent business phone systems. Many 
such systems have connectors, cabling and/or signals 
that are not compatible with standard PC modems. Ac- 
cordingly, it would be impractical for a Remote PC to 
establish a linkage to the Portable Host Unit unless the 
Host PC were moved to a location where a telephone 
jack existed or a long phone cable was run to the Port- 
able Host Unit from wherever an available phone jack 
exists. An acoustical coupler permits a connection to be 
made to a Remote PC simply by placing the most con- 
venient telephone's headset at the Host site into the 
acoustical receptacle on the Portable Host Unit. 
[0304] Under this alternative embodiment, the Porta- 
ble Host Unit would be connected to a Host PC as de- 
scribed in the narrative supporting Fig 1, except (1) no 
direct line linkage would apply, (2) the modem at the 
Host Site would not be plugged directly into a telephone 
line and (3) no other Host Unit's would be daisy-chained 
to the Portable Host Unit. After the Portable Host Unit 
was attached to the Host PC, the TVTRAIN.EXE pro- 
gram could be initiated on the Host PC and the training 
process completed as described in narrative for Fig. 6. 
If thisSraining process had been previously completed 
for this Host PC and the training parameters were stored 
in the Remote PC that will access the Host PC, as de- 
scribed below, the training process need not be repeat- 
ed, after the Portable Host Unit is re-attached to the Host 
PC. In this case, the necessary training parameters 
would be uploaded from the Remote PC to the Host Unit 
via the TVLINK.EXE program when the connection is 
first established, as described below. 
[0305] After the Portable Host Unit is connected to the 
Host PC and the training process completed, if applica- 
ble, a call would be initiated from the Remote PC to the 
most convenient phone number and phone extension, 
if applicable, at the Host Site where the Portable Host 
Unit is located. The person answering the call would 
place the telephone headset on the acoustical coupler 
of the Portable Host Unit to complete the telephone line 
linkage between the Remote PC and Portable Host Unit. 
If the training parameters for the Host PC being ac- 
cessed are stored on the Remote PC's mass storage 
device, the parameters would be up-loaded automati- 
cally by the TVLINK.EXE program to the Portable Host 
Unit's non-volatile RAM storage, immediately after the 
connection to the Portable Host Unit is established. Oth- 
erwise, the training parameters would be automatically 



down-loaded from the Portable Host Unit's non-volatile 
RAM to the Remote PC's mass storage device for use 
in cases where future access may be required to the 
Host PC to eliminate the need for users .at the Host Site 
5 to re-train the Portable Host Unit. Once the connection 
to the Portable Host Unit and the required training pa- 
rameters have either been up-loaded or down-loaded, 
the Remote PC will have access to the Portable Host 
Unit consistent with any other Host Unit, as previously 
10 discussed. Once Host PC is processing is complete, the 
Remote PC user would terminate the connection via the 
TVLINK.EXE program (see narrative for block 754A), 
the Portable Host Unit would beep three times after the 
connection has ended, and someone at the Host Site 
1 $ would then remove the telephone headset from the 
acoustical coupler and return it to it's telephone cradle. 
[0306] With regard to TVLINK.EXE processing on a 
Remote PC, when a call list is updated (see narrative 
for block 715), a symbol such as "!" will be used as part 
20 of the dialing string to indicate a call is being placed to 
a Portable Host Unit. When a call is placed to a Host 
Site (see narrative for block 704) containing this symbol 
as part of the dialing string, TVLINK.EXE will either up- 
load or down-load Host Unit training parameters to or 
25 from the Portable Host Unit, automatically associate the 
stored training parameters with the call-list entry, and 
follow the procedures necessary to establish a connec- 
tion to the Portable Host Unit via an acoustical coupler. 
In addition, the TVLINK.EXE program will preclude se- 
30 lecting the TVLINK.EXE menu option permitting a Re- 
mote user to switch between Host Units (see narrative 
for block 731), since other Host Unit's cannot be pres- 
ently daisy-chained to a Portable Host Unit. 
[0307] The interna! circuitry of a Host Unit presently 
35 provides a general data interface port, herein referred 
to as an "AUX" port to send data out of the Host Unit 
and receive data into the Host Unit from external devic- 
es. Presently, this AUX port has several intended uses. 
[0308] First, this AUX port could be programmed by 
40 the Control CPU to interface with a transmitter, such as 
an X-1 0 transmitter, familiar to persons in the trade, to 
permit a Remote PC to control devices external to a Host 
Unit. For example, a Remote User could select a menu 
option provided by the TVLINK.EXE program causing 
^5 power to be temporarily interupted to remote print serv- 
ers on a network, forcing the print servers to reboot and 
re-attach to a computer network that has failed and been 
successfully re-started. In this example, data required 
by the X-1 0 unit to interupt powerto desired print servers 
so would be sent by software operating in the Control CPU 
to the X-1 0 unit connected to the AUX port. Upon receipt 
of such data, the X-1 0 unit would transmit data to an X- 
1 0 receiver switch module used to supply AC power to 
each print server. Upon receipt of a command ad- 
55 dressed to a specific X-1 0 switch module, AC power for 
that switch module would be interupted. Upon receipt of 
a second command addressed to that switch module 
power would be restored. 
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[0309] Second, this AUX port could be used establish 
a linkage between the Host Unit and the network mon- 
itoring and trouble alert apparatus ("Alert System") such 
as an apparatus like that described in U.S. Patent Ap- 
plication No. 07/966,081 filed October 23, 1992 and as- 
signed to assignee of the present invention , the contents 
of which are incorporated by reference herein. In this 
case, the "Alert System" could share a common phone 
line linkage with Host Unit(s) at a Host Site. In addition, 
a special "Y" style serial cable interface would permit 
the Alert System to continue to transmit and receive se- 
rial data in the same manner, as well as link the Alert 
System's serial port to the AUX port of Host Unit 00. 
[0310] When an alert is received from the Alert Sys- 
tem, the person receiving the alert could enter a pre-set 
code using the keys on theirtouch tone phone indicating 
that the Alert System should suspend processing until 
a second confirming tone is received from a Remote 
PC's modem. Then, the person receiving the alert would 
activate the TVLINK.EXE program on their Remote PC 
to access the Host Site via a direct access (see narrative 
for Block 711) procedure. The TVLINK.EXE program 
would then instruct the Remote PC's modem to go off- 
hook and issue an audible touch tone code indicating 
the Remote PC was ready for the direct connection. Up- 
on hearing this audible touch tone the remote user 
would hang up the telephone (at which point the Remote 
PC will still hold the line connection via the PC's mo- 
dem's direct connect status). Once the confirming touch 
tone was received by the Alert System, the Alert System 
would send a pre-set signal out of its serial port to the 
AUX port of Host Unit 00 instructing the Host Unit tell 
its modem to go off-hook (and thereby complete the di- 
rect connection to the Remote PC). Upon receiving this 
serial signal, the Host Unit's Control CPU would send 
commands out of the Data Out port to the Host Units 
modem instructing the modem to go off hook and issue 
a preset touch tone confirming the Host Unit had taken 
the modem off hook. When the expected touch tones 
from the Host Unit's modem are detected by the Alert 
System, the Alert System would cancel any pending 
phone alerts and go on-hook. At this point, a successful 
direct connection between a Remote PC and a Host Site 
has been accomplished after alert is received without 
losing the phone connection. 

[0311] Synchronizing Host Unit access and Alert Sys- 
tem processing, as described, (1 ) permits both the Alert 
System and Host Unit to successfully share the same 
phone line and thereby minimize phone line costs, (2) 
prevents situations where both a Remote PC and Alert 
system share the same phone line and the Remote PC 
cannot access a Host Unit because the Alert System is 
using the phone line to issue alerts, (3) minimizes situ- 
ations where both a Remote PC and Alert system share 
the same phone line and the Alert System interferes with 
the Remote PC's connection to the Host PC by contin- 
uing to interrupt the phone line by attempting to issue 
pending alerts, and (4) insures the fastest possible ac- 



cess to Host PC's in the event an alert is issued by the 
Alert System. 



5 Claims 

1 . Computer monitoring system for monitoring the in- 
formation displayed on a video display terminal (9, 
15, 19) connectedto, and receiving display inforrna- 

10 tion from, a data processing device (1 0, 1 6, 20), 
characterized in 

that the computer monitoring system comprises in 
addition to the data processing device (1 0, 1 6, 20) 
a microprocessor controlled computer hardware 
1 $ device (8, 13, 18) working even if the data process- 
ing device (10, 16, 20) is locked up and no longer 
processing data or input commands, wherein the 
microprocessor controlled computer hardware de- 
vice (8, 13, 18) includes a video raster signal input 
20 means for receiving a video raster signal represent- 
ative of the information displayed on the video dis- 
play terminal from the data processing device (10, 
16, 20), and a conversion means connected to the 
video raster signal input means for converting the 
25 video raster signal into a digital signal representa- 
tive of the information contained in the video raster 
signal. 

2. System according to claim 1 , characterized in that 
30 said conversion means comprises character deter- 
mination means for determining the identity of each 
character displayed on the video display terminal 
(9, 15, 19) and for generating a digital code indica- 
tive of the identity of said each character displayed 

35 on the video display terminal (9, 15, 19), and, pref- 
erably, wherein said character determination 
meaqs comprises circuitry for generating a series 
of cyclic redundancy checks, wherein each said cy- 
clic redundancy check is generated from the pixel 
^0 information associated with each character location 
on the video display terminal (9, 15, 19). 

3. System according to claim 2, characterized in that 
the system further comprises transmission means 

^5 connected with said conversion means for transmit- 
ting said digital code to a remote location. 

4. System according to claim 3, characterized in that 
the system further comprises: 

so 

reception means at said remote location con- 
nected with said transmission means for receiv- 
ing said digital codes transmitted by said trans- 
mission means; and 

55 

remote video display means connected with 
said reception means for displaying said digital 
codes received from said reception means, 
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said display means showing an image suffi- 
ciently similar to that shown on the video dis- 
play terminal (9, 15, 19) to allow a user to de- 
termine the operational status of the data 
processing device (10, 16, 20). 5 

5. System according to any one of claims 2 to 4, char- 
acterized in that said digital codes are transmitted 
to said remote location in response to a command 
received from said remote location requesting that 10 
said digital codes be transmitted. 

6. System according to any one of claims 2 to 5, char- 
acterized in that the system further comprises in- 
terconnection means for interconnecting a plurality 15 
of said microprocessor controlled computer hard- 
ware devices (8, 13, 18) with one another and for 
allowing a user at said remote location to selectively 
access any one of said microprocessor controlled 
computer hardware devices (8, 13, 18) or its asso- 20 
ciated data processing device (10, 16, 20). 

7. System according to any one of claims 2 to 6, char- 
acterized in that the system further comprises: 

25 

memory means connected with said conver- 
sion means for storing said digital codes to re- 
tain an image of the information displayed on 
the video display terminal (9, 15, 19); and 

30 

control means connected to said memory 
means and said conversion means for monitor- 
ing changes to said image and for storing said 
digital codes representative of said changes in 
said memory means, whereby said memory 35 
means contains a series of image frames that 
can be used by an operator to determine the 
cause of a system failure. 

8. System according to any one of claims 2 to 7, char- 40 
acterized in that the system further comprises: 

training means connected to said character de- 
termination means for generating a predeter- 
mined character display and for storing said 45 
digital codes generated by said character de- 
termination means representative of each char- 
acter on said predetermined display; and 

comparison means connected with said train- so 
ing means and said character determination 
means for comparing said digital codes gener- 
ated for an unknown display on said video dis- 
play terminal (9, 15, 19) with said digital codes 
representative of each character on said pre- 55 
determined display, whereby the identity of 
each character displayed on said unknown dis- 
play can be determined. 



9. System according to any one of the preceding 
claims, characterized in 

that the system further comprises synchronization 
signal input means for receiving from the data 
processing device (10,16, 20) a horizontal synchro- 
nization signal, and pixel clock generating means 
connected with said synchronization signal input 
means and said conversion means for generating 
a pixel clock signal, and/or 

that said data processing device (10, 16, 20) is a 
personal computer, and said video raster signal in- 
put means comprises a circuit interconnected be- 
tween said personal computer and the video display 
terminal (9, 15, 19). 

10. System according to any one of the preceding 
claims, characterized in that the data processing 
device (10, 16, 20) is a personal computer, that the 
video raster signal input means is connected with 
said personal computer for receiving a video raster 
signal and a horizontal synchronization signal from 
said personal computer, and that the system com- 
prises: 

video signal output means connected with said 
video display terminal (9,15,19) and said video 
signal input means for supplying said video 
raster signal and said horizontal synchroniza- 
tion signal to said video display terminal (10, 
16, 20); 

host site command input means located with 
said personal computer for receiving com- 
mands from a host site user to be processed by 
said personal computer; 

command output means connected with said 
local command input means and with a stand- 
ard keyboard interface of said personal compu- 
ter for supplying commands to be processed by 
said personal computer to said standard key- 
board interface of said personal computer; 

transmission means connected with said con- 
version means and said command output 
means for transmitting said digital signal to a 
remote location and for transmitting commands 
received from said remote location to said com- 
mand output means; 

remote command input means at said remote 
location connected with said transmission 
means for receiving commands to be transmit- 
ted to and executed by said personal computer; 
and 

remote video display means for receiving said 
digital signals representative of the information 
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contained in said video raster signal and for dis- 
playing said signals to allow a user at said re- 
mote location to view the information displayed 
on said video display terminal (9, 15, 19) con- 
nected to said personal computer, s 

wherein the conversion means comprises pixel 
clock generating means for generating a pixel clock 
signal; 

whereby computer service personnel at the remote 10 
location can determine the present operating status 
of the file server, determine repair action to betaken 
if necessary, and initiate said repair action by trans- 
mitting commands to be executed by said personal 
computer to said personal computer. is 

11. Method of converting the information contained in 
a video raster signal generated by a data process- 
ing device (10,16, 20) and displayed on a video dis- 
play terminal (9, 15, 19) associated with the data 20 
processing device (10, 16, 20), into a digital repre- 
sentation of that information for monitoring the in- 
formation, 

characterized in 

that the video raster signal is received and convert- 25 
ed into a digital signal representative of the infor- 
mation contained in the video raster signal inde- 
pendently from the data processing device (10, 16, 
20). 

30 

12. Method according to claim 11, characterized in 
that said converting step includes the steps of de- 
termining the identity of each character displayed 
on the video display terminal (9, 15, 19) and gener- 
ating a digital code indicative of the identity of said 35 
each character displayed on the video display ter- 
minal (9, 1 5, 1 9 preferably wherein said step of gen- 
erating a digital code comprises the step of gener- 
ating a series of cyclic redundancy checks from the 
pixel information associated with each character lo- 40 
cation on the video display terminal (9,15,19). 

13. Method according to claim 12, characterized In 
that the method further comprises the step of trans- 
mitting said digital codes to a remote location. *s 

14. Method according to claim 13, characterized in 
that the method further comprises the steps of: 

receiving said digital codes transmitted to said so 
remote location; and 

displaying said digital codes received from said 
remote location to create an image sufficiently 
similar to that shown on the video display ter- 55 
minal (9, 15, 19) to allow a user to determine 
the operational status of the data processing 
device (10, 16, 20). 



15. Method according to any one of claims 12 to 14, 
characterized In that said step of transmitting said 
digital codes to said remote location is performed in 
response to a command received from said remote 
location requesting that said digitarcbdes be trans- 
mitted. 

16. Method according to any one of claims 12 to 15, 
characterized in that the method further compris- 
es the steps of: 

analyzing a predetermined charactersequence 
displayed on the video display terminal (9, 15, 
1 9) to determine the identity of each character 
displayed on said video display terminal (9, 15, 

19) ; 

generating a digital code representative of each 
character in said charactersequence displayed 
on said video display terminal (9, 15, 19); and 

storing said digital codes in a memory, whereby 
future unknown screen displays can be com- 
pared with said digital codes to determine the 
identity of characters displayed on said future 
unknown screen displays. 

17. Method according to any one of claims 11 to 16, 
characterized in that the method further compris- 
es the steps of: 

receiving a horizontal synchronization signal 
from the data processing device (10, 16, 20); 
and 

generating a pixel clock signal in synchroniza- 
tion with said horizontal synchronization signal, 
and/orthat said data processing device (1 0, 16, 

20) is a personal computer, and said video 
raster signal is intercepted between said per- 
sonal computer and the video display terminal 
(9,15,19). 



PatentansprOche 

1. Computeruberwachungssystem zur Oberwachung 
derauf einem Videoanzeigegerat bzw. -terminal (9, 
15, 19) angezeigten Information, das an ein Daten- 
verarbeitungsgerat (10, 16, 20) angeschlossen ist 
und Anzeigeinformation davon erhalt, 
dadurch gekennzeichnet, 
daft das Computeruberwachungssystem zusatz- 
lich zum Datenverarbeitungsgerat (10, 16, 20) ein 
mikroprozessorgesteuertes Computerhardwarege- 
rat (8, 13, 18) aufweist, das auch dann funktioniert 
bzw. arbeitet, wenn das Datenverarbeitungsgerat 
(10, 16, 20) abgestiirzt bzw. blockiert ist und keine 
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Daten Oder Eingabebefehle mehr verarbeitet, wo- 6. 
bei das mikroprozessorgesteuerte Computerhard- 
waregerat(8, 13, 18) ein Videorastersignaleingabe- 
mittel zum Empfang eines Videorastersignals, das 
der Information entspricht, die vom Datenverarbei- 5 
tungsgerat (1 0, 1 6, 20) auf dem Videoanzeigegerat 
angezeigt wird, und ein Umwandlungsmittel, das 
mit dem Videorastersignaleingabemittel verbunden 
ist, um das Videorastersignal in ein Digitalsignal 
umzuwandeln, das der im Videorastersignal enthal- io 
tenen Information entspricht, umfaGt. 

7. 

System nach Anspruch 1, dadurch gekennzeich- 
net, daB das Umwandlungsmittel ein Zeichener- 
kennungsmittel umfaBt, um die Identitat jedes Zei- 15 
chens zu erkennen bzw. zu bestimmen, das auf 
dem Videoanzeigegerat (9, 15, 19) angezeigt wird, 
und um einen Digitalcode zu erzeugen, der die 
Identitat des auf dem Videoanzeigegerat (9,15,19) 
angezeigten Zeichens angibt, und vorzugsweise 20 
wobei das Zeichenerkennungsmittel Schaltungen 
zum Erzeugen einer Reihe von CRC-Werten bzw. 
Durchfuhren von zyklischen Redundanzchecks 
umfaBt, wobei jeder CRC-Wert aus der Pixelinfor- 
mation erzeugt bzw. jeder zyklische Redundanz- 25 
check von der Pixelinformation durchgefuhrt wird, 
die jeder Zeichenposition auf dem Videoanzeigege- 
rat (9, 15, 19) zugeordnet ist. 

System nach Anspruch 2, dadurch gekennzeich- 30 
net, daB das System ferner ein Ubertragungsmittel 
aufweist, das mit dem Umwandlungsmittel verbun- 8. 
den ist, um den Digitalcode an eine entfernte Stelle 
Oder Fernsite zu ubertragen. 

35 

System nach Anspruch 3, dadurch gekennzeich- 
net, daB das System ferner aufweist: 

ein Empfangsmittel an der entfernten Stelle, 
das mit dem Ubertragungsmittel verbunden ist, 40 
um die von dem Ubertragungsmittel ubertrage- 
nen Digitalcodes zu empfangen; und 

ein Fernvideoanzeigeitiittel, das mit dem Emp- 
fangsmittel verbunden ist, um die vom Emp- 45 
fangsmittel empfangenen Digitalcodes anzu- 
zeigen, wobei dieses Anzeigemittel ein Bild an- 
zeigt, das dem auf dem Videoanzeigegerat (9, 
15, 19) angezeigten ausreichend gleicht, damit 
ein Benutzer den Betriebszustand des Daten- 50 
verarbeitungsgerats (10, 16, 20) erkennen 
kann. 

9. 

System nach einem der Anspruche 2 bis 4, da- 
durch gekennzeichnet, daB die Digitalcodes zur 55 
entfernten Stelle ubertragen werden, wenn von der 
entfernten Stelle ein Befehl empfangen wird, der die 
Ubertragung der Digitalcodes anfordert. 



System nach einem der Anspruche 2 bis 5, da- 
durch gekennzeichnet, daB das System ferner ein 
Verbindungsmittel zur Verbindung einer Vielzahl 
von mikroprozessorgesteuertenCqmputerhardwa- 
regeraten (8, 13, 18) aufweist, um einem Benutzer 
an der Fernsite bzw. entfernten Stelle den selekti- 
ven Zugriff auf eines der mikroprozessorgesteuer- 
ten Computerhardwaregerate (8, 13, 18) oderdes- 
sen zugehoriges Datenverarbeitungsgerat (10, 16, 
20) zu erlauben. 

System nach einem der Anspruche 2 bis 6, da- 
durch gekennzeichnet, daB das System ferner 
aufweist: 

ein Speichermittel zum Speichern der Digital- 
codes, das mit dem Umwandlungsmittel ver- 
bunden ist, um ein Bild der auf dem Videoan- 
zeigegerat (9, 15, 19) angezeigten Information 
zu speichern; und 

ein Steuermittel, das mit dem Speichermittel 
und dem Umwandlungsmittel verbunden ist, 
um Anderungen in dem Bild zu uberwachen 
und die Digitalcodes, die diesen Anderungen 
entsprechen, im Speichermittel zu speichern, 
wobei das Speichermittel eine Reihe von Ein- 
zelbildern enthalt, die von einem Bediener ver- 
wendet werden konnen, um die Ursache eines 
Systemausfalls zu ermitteln. 

System nach einem der Anspruche 2 bis 7, da- 
durch gekennzeichnet, daB das System ferner 
aufweist: 

ein Trainingsmittel, das mit dem Zeichenerken- 
^nungsmittel verbunden ist, um eine vorgegebe- 
ne Zeichenanzeige zu erzeugen und die vom 
Zeichenerkennungsmittel erzeugten Digitalco- 
des, die jedes Zeichen der vorgegebenen An- 
zeige rep rase nti ere n, zu speichern; und 

eine Vergleichsmittel, das mit diesem Trai- 
ningsmittel verbunden ist, um die Digitalcodes, 
die fur eine unbekannte Anzeige auf dem Vi- 
deoanzeigegerat (9, 15, 19) erzeugt werden, 
mit den Digitalcodes zu vergleichen, die jedes 
Zeichen der vorgegebenen Anzeige reprasen- 
tieren, wodurch die Identitat jedes Zeichens, 
das auf der unbekannten Anzeige angezeigt 
wird, festgestellt werden kann. 

System nach einem der vorstehenden Anspruche, 
dadurch gekennzeichnet, 

daB das System femerein Synchronisationssignal- 
eingabemittel zum Empfangen eines Horizontal- 
synchronisationssignals vom Datenverarbeitungs- 
gerat (10,16, 20) und ein Pixeltakterzeugungs mittel 
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aufweist, das mit dem Synchronisationssignalein- 
gabemittel und dem Umwandlungsmittel verbun- 
den 1st, urn ein Pixeltaktsignal zu erzeugen, und/ 
oder 

daB das Date nverarbeitungsge rat (10, 16, 20) ein 5 
Personal-Computer ist und das Videorastersignal- 
eingabemittel eine Schaltung aufweist, die zwi- 
schen den Personal-Computer und das Videoan- 
zeigegerat (9, 15, 19) geschaltet ist. 

10 

10. System nach einem der vorstehenden Anspruche, 
dadurch gekennzeichnet, daB das Datenverar- 
beitungsgerat (10, 16, 20) ein Personal-Computer 
ist, daB das Videorastersignaleingabemittel mit 
dem Personal-Computer verbunden ist, urn vom 15 
Personal-Computer ein Videorastersignal und ein 
Horizontalsynchronisationssignal zu empfangen, 
und daB das System aufweist: 

ein Videosignalausgabemittel, das mit dem Vi- 20 
deoanzeigegerat (9, 15, 19) und dem Videosi- 
gnaleingabemittel verbunden ist, um das Vi- 
deorastersignal und das Horizontalsynchroni- 
sationssignal zum Videoanzeigegerat (10, 16, 
20) auszugeben; 25 

ein Befehlseingabemittel an der Hostsite, das 
an dem Personal-Computer angeordnet ist, um 
Befehle von einem Benutzer an der Hostsite zu 
empfangen, die vom Personal-Computer zu so 
verarbeiten sind; 



se Signale anzeigt, um einem Benutzer an der 
Fernsitze bzw. entfernten Stelle zu erlauben, 
die Information zu betrachten, die am Videoan- 
zeigegerat (1 0, 1 6, 20) angezeigt wird, das am 
Personal-Computer angeschloss'en ist, 

wobei das Umwandlungsmittel ein Pixeltakterzeu- 
gungsmittel umfaBt, um ein Pixeltaktsignal zu er- 
zeugen; 

wodurch Computerservicepersonal an der Femsite 
bzw. entfernten Stelle in der Lage ist, den aktuelien 
Betriebszustand des File- bzw. Dateiservers zu er- 
kennen, eine ReparaturrnaBnahme festzulegen, 
falls notwendig, und diese ReparaturrnaBnahme 
einzuleiten, indem Befehle, die vorn Personal-Com- 
puter auszufuhren sind, an den Personal-Computer 
ubertragen werden. 

11. Verfahren zum Umwandeln der Information, die in 
einem Videorastersignal enthalten ist, das von ei- 
nem Datenverarbeitungsgerat (10, 16, 20) erzeugt 
und an einem dem Datenverarbeitungsgerat (10, 
1 6, 20) zugeordneten Videoanzeigegerat (9, 1 5, 1 9) 
angezeigt wird, in eine digitale Darstellung dieser 
Information zur Uberwachung der Information, 
dadurch gekennzeichnet, 

daB das Videorastersignal empfangen und in ein 
Digitalsignal umgewandelt wird, das der im Video- 
rastersignal enthalten en Information entspricht, un- 
abhangig vom Datenverarbeitungsgerat (10, 16, 
20). 

12. Verfahren nach Anspruch 11, dadurch gekenn- 
zeichnet, daB der Umwandlungsschritt die Schritte 
des Bestimmens der Identitat jedes Zeichens, das 
auf dem Videoanzeigegerat (9, 15, 19) angezeigt 
wird^nd des Erzeugens eines Digltalcodes um- 
faBt, der die Identitat jedes Zeichens angibt, das auf 
dem Videoanzeigegerat (9, 15, 19) angezeigt wird, 
vorzugsweise wobei der Schritt des Erzeugens ei- 
nes Digitalcodes den Schritt des Erzeugens einer 
Reihe von CRC-Werten aus der Pixelinformation 
bzw. des Durchfuhrens von zyklischen Redundanz- 
checks der Pixelinformation umfaBt, die jeder Zei- 
chenposition auf dem Videoanzeigegerat (9, 15, 19) 
zugeordnet ist. 

13. Verfahren nach Anspruch 12, dadurch gekenn- 
zeichnet, daB das Verfahren ferner den Schritt des 
Ubertragens der Digitalcodes an eine Fernsite bzw. 
entfernte Stelle umfaBt. 

14. Verfahren nach Anspruch 13, dadurch gekenn- 
zeichnet, daB das Verfahren ferner aufweist die 
Schritte: 

Empfangen der Digitalcodes, die zur Fernsite 
bzw. entfernten Stelle ubertragen werden; und 



ein Befehlsausgabemrttel, das mit dem lokalen 
Befehlseingabemittel und mit der standardma- 
Bigen Tastaturschnlttstelle des Personal -Com- 35 
puters verbunden ist, um uber die standardma- 
BigeTastaturschnittstelle des Personal-Compu- 
ters Befehle auszugeben, die vom Perso- 
nal-Computer zu verarbeiten sind; 

40 

ein Ubertragungsmittel, das mit dem Umwand- 
lungsmittel und dem Befehlsausgabemittel ver- 
bunden ist, um das Digitalsignal zu einer Fern- 
site bzw. entfernten Stelle zu ubertragen und 
um Befehle, die von dieser Femsite bzw. ent- 
femten Stelle empfangen werden, an das Be- 
fehlsausgabemittel zu ubertragen; 

ein Fernbefehlseingabemittel an der Femsite 
bzw. entfernten Stelle, das mit dem Ubertra- 50 
gungsmittel verbunden ist, um Befehle zu emp- 
fangen, die an den Personal-Computer zu 
ubertragen und von diesem auszufuhren sind; 
und 

55 

ein Fernvideoanzeigemittel, das die Digitalsi- 
gnale empfangt, die der im Videorastersignal 
enthaltenen Information entsprechen, und die- 
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Anzeigen der an der Fernsite bzw. entfernten 
Stelle empfangenen Digitalcodes, um ein Bild 
zu erzeugen, das dem auf dem Videoanzeige- 
gerat (9, 15, 19) angezeigten ausreichend 
gleicht, um einem Benutzer das Erkennen des 
Betriebszustands des Datenverarbeitungsge- 
rats (10, 16, 20) zu erlauben. 

1 5. Verfahren nach einem der Anspruche 1 2 bis 1 4, da- 
durch gekennzeichnet, daB der Schritt des Uber- 
tragens der Digitalcodes zur Fernsite bzw. entfern- 
ten Stelle durchgefuhrt wird, nachdem von der 
Fernsite bzw. entfernten Stelle ein Befehl empfan- 
gen wurde, der die Ubertragung dieser Digitalcodes 
anfordert. 

16. Verfahren nach einem der Anspruche 12 bis 15, da- 
durch gekennzeichnet, daft das Verfahren ferner 
aufweist die Schritte: 

Analysieren einer vorgegebenen Zeichenfolge, 
die auf dem Videoanzeigegerat (9, 15, 19) an- 
gezeigt wird, um die Identitat jedes Zeichens 
zu erkennen, das auf dem Videoanzeigegerat 
(9, 15, 19) angezeigt wird; 

Erzeugen eines Digitalcodes, der jedem Zei- 
chen in der Zeichenfolge entspricht, die auf 
dem Videoanzeigegerat (9, 15, 19) angezeigt 
wird; 

Speichern der Digitalcodes in einem Speicher, 
wodurch kunftige unbekannte Bildschirmanzei- 
gen mit den Digitalcodes verglichen werden 
konnen, um die Identitat der Zeichen zu ermit- 
teln, die auf den kunftigen unbekannten Bild- 
schirmanzeigen angezeigt werden. 

17. Verfahren nach einem der Anspruche 11 bis 16, da- 
durch gekennzeichnet, daB das Verfahren ferner 
aufweist die Schritte: 

Empfangen eines Horizontalsynchronisations- 
signals vom Datenverarbeitungsgerat (10, 16, 
20); und 

Erzeugen eines Pixeltaktsignals, das mit dem 
Horizontalsynchronisationssignal synchron ist, 
und/oder daB das Datenverarbeitungsgerat 
(10,16, 20) ein Personal-Computer ist und das 
Videorastersignal zwischen dem Perso- 
nal-Computer und dem Videoanzeigegerat (9, 
15, 19) abgefangen bzw. abgenommen wird. 



Revendications 

1. Systeme de surveillance informatique pour sur- 



veiller les informations affichees sur un appareil de 
visualisation (9, 15, 19) relie & un dispositif de trai- 
tement de donnees (10,16, 20) et recevant des in- 
formations d'affichages & partir dudit dispositif, ca- 
racterise en ce que le systeme de surveillance in- 
formatique comprend, en plus du dispositif de trai- 
tement de donnees (10,16, 20), un dispositif de ma- 
teriel informatique (8, 13,18) commande par un mi- 
croprocesseur qui travaille meme lorsque le dispo- 
sitif de traitement de donnees (10,16, 20) et ne trai- 
te plus des donnees ou des commandes d'entree, 
dans lequel le dispositif de materiel informatique 
commande par un microprocesseur (8, 13, 18) en- 
globe un moyen d'entree de signaux de trame video 
pourrecevoirun signal de trame video representatif 
des informations affichees sur I'appareil de visuali- 
sation & partir du dispositif de traitement de don- 
nees (10, 16, 20) et un moyen de conversion relie 
au moyen d'entree de signaux de trame video pour 
transformer les signaux de trame video en un signal 
numerique representatif des informations conte- 
nues dans le signal de trame video. 

2. Systeme selon la revendication 1 , caracterise en 
25 ce que ledit moyen de conversion comprend un 
moyen de determination de caracteres pour deter- 
miner Pidentite de chaque caractere affiche sur I'ap- 
pareil de visualisation (9, 15, 19) et pour generer un 
code numerique indiquant I'identite desdits carac- 
30 teres respectifs affiches sur I'appareil de visualisa- 
tion (9, 15, 19) et de preference, dans lequel ledit 
moyen de determination de caracteres comprend 
des circuits pour generer une serie de controles par 
redondance cyclique, dans lequel chacun desdits 
35 contrdles par redondance cyclique est genere par 
les informations en forme d'elements d'images as- 
soatees & I'emplacement de chaque caractere sur 
I'appareil de visualisation (9, 15, 19). 



40 3. Systeme selon la revendication 2, caracterise en 
ce que le systeme comprend en outre un moyen de 
transmission relie audit moyen de conversion pour 
transmettre ledit code numerique k un endroit eloi- 
gne. 

45 

4. Systeme selon la revendication 2 ou 3, caracterise 
en ce que le systeme comprend en outre : 

un moyen de reception audit endroit eloigne re- 
50 Me audit moyen de transmission pour recevoir 

lesdits codes numeriques transmis par ledit 
moyen'de transmission ; et 
un moyen de visualisation a distance relie audit 
moyen de reception pour afficher lesdits codes 
55 numeriques recus par ledit moyen de recep- 

tion, ledit moyen de visualisation representant 
une image suffisamment similaire d celle repre- 
sentee sur I'appareil de visualisation (9,15,19) 
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pour permettre a un utilisateur de determiner le 
statut operationnel du dispositif de traitement 
de donnees (10, 16, 20). 

5. Systeme selon Tune quelconque des revendica- 5 
tions 2 a 4, caracterise en ce que iesdits codes 
numeriques sont transmis audit endroit eioigne en 
reponse a une commande recue dudit endroit eioi- 
gne reclamant la transmission desdits codes num§- 
riques. 10 

6. Systeme selon Tune quelconque des revendica- 
tions 2 a 5, caracterise en ce que le systeme com- 
prend en outre un moyen d'interconnexion pour in- 
terconnecter plusieurs desdits dispositifs de mate- 15 
riel informatique commandes par un microproces- 
seur (8, 13, 18) Tun avec I'autre et pour permettre 

a un utilisateur audit endroit 6loign6 d'acceder de 
manifere selective a Tun quelconque des dispositifs 
de materiel informatique commandos par un micro- 20 
prpcesseur (8, 1 3, 1 8) ou a Tun quelconque de leurs 
dispositifs de traitement de donnees associes (10, 
16, 20). 

7. Systeme selon Tune quelconque des revendica- 25 
tions 2 a 6, caracterise en ce que ie systeme com- 
prend en outre : 



8. Systeme selon Tune quelconque des revendica- 45 
tions 2 a 7, caracterise en ce que le systeme com- 
prend en outre : 



meriques gen6r6s pour un affichage inconnu 
sur ledit appareii de visualisation (9, 15, 19). 
avec Iesdits codes numeriques representatifs 
de chaque caractere sur ledit affichage prede- 
termine, par lequel Pidentite de chaque carac- 
tere aff ich6 sur ledit affichage inconnu peut etre 
determinee. 

9. Systeme selon Tune quelconque des revendica- 
tions ptec§dentes, caracterise en ce que le syste- 
me comprend en outre un moyen d'entree de signal 
de synchronisation pour recevoir, a partir du dispo- 
sitif de traitement de donnees (10, 16,20), unsignal 
de synchronisation horizontale, et un moyen de ge- 
neration d'horloge sous forme d'eiements d'images 
relie audit moyen d'entree de signal de synchroni- 

, sation et audit moyen de conversion pour g£n£rer 
un signal d'horloge sous forme d'eiements d'ima- 
ges, et/ou 

en ce que ledit dispositif de traitement de donnees 
(10, 16, 20) est un ordinateur personnel, ledit 
moyen d'entree de signal de trame video compre- 
nant un circuit interconnects entre ledit ordinateur 
personnel et I'appareil de visualisation (9, 15, 19). 

10. Systeme selon I'une quelconque des revendica- 
tions pr6c6dentes, caracterise en ce que le dispo- 
sitif de traitement de donnees (10, 16, 20) est un 
ordinateur personnel, en ce que le moyen d'entree 
de signal de trame video est reli6 audit ordinateur 
personnel pour recevoir un signal de trame video et 
un signal de synchronisation horizontale a partir du- 
dit ordinateur personnel, et en ce que le systeme 
comprend 

un moyen de sortie de signaux video relie 
audit appareii de visualisation (9, 15, 19) et audit 
moves d'entr6e de signaux video pour acheminer 
Iesdits signaux de trame video et ledit signal de syn- 
chronisation horizontale audit appareii de visualisa- 
tion (10, 16, 20) ; 

un moyen d'entr6e de commande au site hdte 
relie audit ordinateur personnel pour recevoir des 
commandes 6mises par un utilisateur du site note 
qui doivent etre traitees par ledit ordinateur 
personnel ; 

un moyen de sortie de commande relie audit 
moyen d'entree de commande local et a une inter- 
face de clavier standard dudit ordinateur personnel 
pour acheminer des commandes qui doivent etre 
traitees par ledit ordinateur personnel a ladite inter- 
face de clavier standard, dudit ordinateur 
personnel ; 

un moyen de transmission relie audit moyen 
de conversion et audit moyen de sortie de comman- 
de pour transmettre Iesdits signaux numeriques a 
un endroit 6loign6 pour transmettre la commande 
recue depuis ledit endroit eioigne audit moyen de 
sortie de commande ; 



un moyen destruction relie audit moyen de de- 
termination de caracteres pour generer un affi- so 
chage de caracteres predetermine et pour m6- 
moriser Iesdits codes numeriques generes par 
ledit moyen de determination de caracteres re- 
presentatifs de chaque caractere sur ledit affi- 
chage predetermine ; et 55 
un moyen de comparaison relie audit moyen 
destruction et audit moyen de determination 
de caracteres pour comparer Iesdits codes nu- 



ts 



20 



un moyen de memoire relie audit moyen de 
conversion pour m6moriser Iesdits codes nu- 30 
meriques afin de conserver une image des in- 
formations affich6es sur I'appareil de visualisa- 
tion (9, 15, 19) ; et 

un moyen de commande relie audit moyen de 
memoire et audit moyen de conversion pour 35 
surveiller des changements apportes a ladite 
image et pour memoriser Iesdits codes nume- 
riques representatifs desdits changements in- 
tervenus dans ledit moyen de memoire, dans 
lequel ledit moyen de memoire contient une s6- 40 
he d'images video qui peuyent §tre utilis6es par 
un op6rateur pour determiner la cause d'une 
detail lance du systeme. 
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un moyen d'entr6e de commande k distance 
audit endroit eioigne relie audit moyen de transmis- 
sion pour recevoir des commandes qui doivent §tre 
transmises audit ordinateur personnel et executees 
par ce dernier ; et 

un moyen d'affichage video k distance pour 
recevoir lesdits signaux numeriques rep res en tat if s 
des informations contenues dans ledit signal de tra- 
me video et pour aff icher lesdits signaux af in de per- 
mettre k un utilisateur audit endroit eioigne de vi- 
sualiser les informations affichees sur ledit appareil 
de visualisation (9,15,19) relie audit ordinateur per- 
sonnel, 

dans lequel le moyen de conversion comprend un 
moyen de generation d'horloge sous forme d'6le- 
ments d'images pour generer un signal d'horloge 
sous forme d'eiements d'images ; 
par lequel le personnel propose k I'entretien des 
systemes informatiques k I'endroit eioigne est en 
mesure de determiner I'etat operationnel existant 
du serveur de fichiers, de determiner le fait de sa- 
voir si une action de reparation doit etre entreprise, 
et de declencher ladite action de reparation par 
transmission de commandes &executer par ledit or- 
dinateur personnel audit ordinateur personnel. 

1 1 . Procede de conversion des informations contenues 
dans un signal de trame video genere par un dis- 
positif de traitement de donnees (10, 16, 20) et af- 
fichees sur un appareil de visualisation (9, 15, 19) 
associe au dispositif de traitement de donnees (10, 
16, 20), en une representation numerique des infor- 
mations pour surveiller les informations, caracteri- 
se en ce que le signal de trame video est regu et 
converti en un signal numerique representatif des 
informations contenues dans le signal de trame vi- 
deo, independamment du dispositif de traitement 
de donnees (10, 16, 20). 

12. Procede selon la revendication 11 , caracterise en 
ce que ladite etape de conversion englobe les 6ta- 
pes consistant k determiner I'identite de chaque ca- 
ractere affiche sur I'appareil de visualisation (9, 15, 
19) et k generer un code numerique indiquant 
i'identite de chaque caractere respectif affiche sur 
I'appareilde visualisation (9, 15, 19), de preference 
dans lequel ladite etape consistant k generer un co- 
de numerique comprend I'etape consistant k gene- 
rer une serie de controles par redondance cyclique 
k partir des informations sous forme d'eiements 
d'images associees k {'emplacement de chaque ca- 
ractere sur I'appareil de visualisation (9, 15, 19). 

13. Procede selon la revendication 12, caracterise en 
ce que le procede comprend en outre I'etape con- 
sistant k transmettre lesdits codes numeriques k un 
endroit eioigne. 



14. Procede selon la revendication 13, caracterise en 
ce que le proc6d6 comprend en outre les etapes 
consistant k : 

5 recevoir lesdits codes numeriques transmis 

audit endroit eioigne ; et 
aff icher lesdits codes numeriques regus depuis 
ledit endroit eioigne afin de creer une image 
suffisamment similaire a celle representee sur 
10 I'appareil de visualisation (9, 15, 19) pour per- 

mettre un utilisateur de determiner I'etat opera- 
tionnel du dispositif de traitement de donnees 
(10, 16,20). 

*5 15. Procede selon Tune queiconque des revendications 
12 k 14, caracterise en ce que ladite etape de 
transmission desdits codes numeriques audit en- 
droit eioigne est mise en oeuvre en reponse k une 
commande regue depuis ledit endroit eioigne recla- 
20 mant la transmission desdits codes numeriques. 

16. Procede selon I'une queiconque des revendications 
12 & 15, caracterise en ce que le procede com- 
prend en outre ies etapes consistant k : 

25 

analyser une sequence de caracteres prede- 
terminee, affichee sur I'appareil de visualisa- 
tion (9, 15, 19) afin de determiner I'identite de 
chaque caractere affiche sur ledit appareil de 

30 visualisation (9, 15, 19) ; 

generer un code numerique representatif de 
chaque caractere dans ladite sequence de ca- 
racteres affichee sur ledit appareil de visualisa- 
tion (9, 15, 19) ; et 

35 .placer lesdits codes numeriques dans une me- 

moire, par lequel des affichages d'ecrans in- 
-^connus futurs peuvent §tre compares audits 
codes numeriques pour determiner I'identite 
des caracteres affich6s sur lesdits affichages 

40 d'ecrans inconnus futurs. 

1 7. Procede selon le queiconque des revendications 1 1 
k 16, caracterise en ce que le procede comprend 
en outre les etapes consistant & : 



recevoir un signal de synchronisation horizon- 
tale a partir du dispositif de traitement de don- 
nees (10, 16, 20) ; et 

generer un signal d'horloge sous forme d'eie- 
50 ments d'images en synchronisation avec ledit 

signal de synchronisation horizontale, et/ou en 
ce que ledit dispositif de traitement de don nees 
(10,16, 20) est un ordinateur personnel et ledit 
signal de trame video est intercepte entre ledit 
55 ordinateur personnel et I'appareil de visualisa- 

tion (9, 15, 19). 
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